summaryrefslogtreecommitdiff
path: root/perl
AgeCommit message (Collapse)AuthorFilesLines
2014-01-13Merge branch 'jn/pager-lv-default-env'Libravatar Junio C Hamano1-0/+1
Just like we give a reasonable default for "less" via the LESS environment variable, specify a reasonable default for "lv" via the "LV" environment variable when spawning the pager. * jn/pager-lv-default-env: pager: set LV=-c alongside LESS=FRSX
2014-01-07pager: set LV=-c alongside LESS=FRSXLibravatar Jonathan Nieder1-0/+1
On systems with lv configured as the preferred pager (i.e., DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the environment) git commands that use color show control codes instead of color in the pager: $ git diff ^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m ^[[1mindex aa4f0b2..17e113e 100644^[[m ^[[1m--- a/.mailfilter^[[m ^[[1m+++ b/.mailfilter^[[m ^[[36m@@ -1,11 +1,58 @@^[[m "less" avoids this problem because git uses the LESS environment variable to pass the -R option ('output ANSI color escapes in raw form') by default. Use the LV environment variable to pass 'lv' the -c option ('allow ANSI escape sequences for text decoration / color') to fix it for lv, too. Noticed when the default value for color.ui flipped to 'auto' in v1.8.4-rc0~36^2~1 (2013-06-10). Reported-by: Olaf Meeuwissen <olaf.meeuwissen@avasys.jp> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-27git-svn: workaround for a bug in svn serf backendLibravatar Roman Kagan1-2/+8
Subversion serf backend in versions 1.8.5 and below has a bug(*) that the function creating the descriptor of a file change -- add_file() -- doesn't make a copy of its third argument when storing it on the returned descriptor. As a result, by the time this field is used (in transactions of file copying or renaming) it may well be released, and the memory reused. One of its possible manifestations is the svn assertion triggering on an invalid path, with a message svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed. This patch works around this bug, by storing the value to be passed as the third argument to add_file() in a local variable with the same scope as the file change descriptor, making sure their lifetime is the same. * [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder] Cc: Benjamin Pabst <benjamin.pabst85@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Roman Kagan <rkagan@mail.ru>
2013-09-06git-svn: fix termination issues for remote svn connectionsLibravatar Uli Heller1-0/+8
git-svn used in combination with serf to talk to svn repository served over HTTPS dumps core on termination. This is caused by a bug in serf, and the most recent serf release 1.3.1 still exhibits the problem; a fix for the bug exists (see https://code.google.com/p/serf/source/detail?r=2146). Until the bug is fixed, work around the issue within the git perl module Ra.pm by freeing the private copy of the remote access object on termination, which seems to be sufficient to prevent the error from happening. Note: Since subversion-1.8.0 and later do require serf-1.2.1 or later, this issue typically shows up when upgrading to a recent version of subversion. Credits go to Jonathan Lambrechts for proposing a fix to Ra.pm, Evgeny Kotkov and Ivan Zhakov for fixing the issue in serf and pointing me to that fix. Signed-off-by: Uli Heller <uli.heller@daemons-point.com> Tested-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18Git.pm: revert _temp_cache use of temp_is_lockedLibravatar Kyle J. McKay1-1/+1
When the temp_is_locked function was introduced, there was a desire to make _temp_cache use it. Unfortunately due to the various tests and logic flow involved changing the _temp_cache function to use the new temp_is_locked function is problematic as _temp_cache needs a slightly different test than is provided by the temp_is_locked function. This change reverts use of temp_is_locked in the _temp_cache function and restores the original code that existed there before the temp_is_locked function was added. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-07git-svn: allow git-svn fetching to work using serfLibravatar Kyle J. McKay1-2/+4
When attempting to git-svn fetch files from an svn https?: url using the serf library (the only choice starting with svn 1.8) the following errors can occur: Temp file with moniker 'svn_delta' already in use at Git.pm line 1250 Temp file with moniker 'git_blob' already in use at Git.pm line 1250 David Rothenberger <daveroth@acm.org> has determined the cause to be that ra_serf does not drive the delta editor in a depth-first manner [...]. Instead, the calls come in this order: 1. open_root 2. open_directory 3. add_file 4. apply_textdelta 5. add_file 6. apply_textdelta When using the ra_serf access method, git-svn can end up needing to create several temp files before the first one is closed. This change causes a new temp file moniker to be generated if the one that would otherwise have been used is currently locked. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-07Git.pm: add new temp_is_locked functionLibravatar Kyle J. McKay1-2/+31
The temp_is_locked function can be used to determine whether or not a given name previously passed to temp_acquire is currently locked. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-09git-svn: added an --include-path flagLibravatar Paul Walmsley1-2/+14
The SVN::Fetcher module is now able to filter for inclusion as well as exclusion (as used by --ignore-path). Also added tests, documentation changes and git completion script. If you have an SVN repository with many top level directories and you only want a git-svn clone of some of them then using --ignore-path is difficult as it requires a very long regexp. In this case it's much easier to filter for inclusion. [ew: remove trailing whitespace] Signed-off-by: Paul Walmsley <pjwhams@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-09Git::SVN::*: add missing "NAME" section to perldocLibravatar Jonathan Nieder4-0/+8
lexgrog(1) relies on the NAME section to find a manpage's subject's name and description for easy access later using "man -k". Add the section it expects. Noticed using lintian. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-01Merge branch 'hb/git-pm-tempfile'Libravatar Junio C Hamano1-1/+1
* hb/git-pm-tempfile: Git.pm: call tempfile from File::Temp as a regular function
2013-04-29Git.pm: call tempfile from File::Temp as a regular functionLibravatar H. Merijn Brand1-1/+1
We call File::Temp's "tempfile" function as a class method, but it was never designed to be called this way. Older versions seemed to tolerate it, but as of File::Temp 0.23, it blows up like this: $ git svn fetch 'tempfile' can't be called as a method at .../Git.pm line 1117. Fix it by calling it as a regular function, just inside the File::Temp namespace. Signed-off-by: H. Merijn Brand <h.m.brand@xs4all.nl> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15Merge branch 'tr/perl-keep-stderr-open'Libravatar Junio C Hamano1-3/+3
Closing (not redirecting to /dev/null) the standard error stream is not a very smart thing to do. Later open may return file descriptor #2 for unrelated purpose, and error reporting code may write into them. * tr/perl-keep-stderr-open: t9700: do not close STDERR perl: redirect stderr to /dev/null instead of closing
2013-04-12Sync with 'maint'Libravatar Junio C Hamano3-3/+3
* maint: Correct common spelling mistakes in comments and tests kwset: fix spelling in comments precompose-utf8: fix spelling of "want" in error message compat/nedmalloc: fix spelling in comments compat/regex: fix spelling and grammar in comments obstack: fix spelling of similar contrib/subtree: fix spelling of accidentally git-remote-mediawiki: spelling fixes doc: various spelling fixes fast-export: fix argument name in error messages Documentation: distinguish between ref and offset deltas in pack-format i18n: make the translation of -u advice in one go
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini3-3/+3
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: Typo fix: replacing it's -> its t: make PIPE a standard test prerequisite archive: clarify explanation of --worktree-attributes t/README: --immediate skips cleanup commands for failed tests
2013-04-11Typo fix: replacing it's -> itsLibravatar Benoit Bourbie1-2/+2
Signed-off-by: Benoit Bourbie <benoit.bourbie@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-04perl: redirect stderr to /dev/null instead of closingLibravatar Thomas Rast1-3/+3
On my system, t9100.1 triggers the following warning: ==352== Syscall param write(buf) points to uninitialised byte(s) ==352== at 0x57119C0: __write_nocancel (in /lib64/libc-2.17.so) ==352== by 0x56AC1D2: _IO_file_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so) ==352== by 0x56AC0B1: new_do_write (in /lib64/libc-2.17.so) ==352== by 0x56AD3B4: _IO_do_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so) ==352== by 0x56AD6FE: _IO_file_overflow@@GLIBC_2.2.5 (in /lib64/libc-2.17.so) ==352== by 0x56AE3D8: _IO_default_xsputn (in /lib64/libc-2.17.so) ==352== by 0x56ACAA2: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.17.so) ==352== by 0x5682133: buffered_vfprintf (in /lib64/libc-2.17.so) ==352== by 0x567CE9D: vfprintf (in /lib64/libc-2.17.so) ==352== by 0x5687096: fprintf (in /lib64/libc-2.17.so) ==352== by 0x4E7AC5: vreportf (usage.c:15) ==352== by 0x4E7B14: die_builtin (usage.c:38) The actual complaint appears to be a bug in the underlying implementation. What's interesting here is that it is apparently _triggered_ by closing stderr, which results in (from strace) write(2, "fatal: Needed a single revision\n", 32) = -1 EBADF (Bad file descriptor) write(2, "\0", 1) = -1 EBADF (Bad file descriptor) Closing stderr is a bad idea anyway: there is a very real chance that we print fatal error messages to some other file that just happens to be opened on the now-free FD 2. So let's not do that. As pointed out by Eric Wong (thanks), the initial close needs to go: die() would again write nowhere if we close STDERR beforehand. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27git-svn: Support custom tunnel schemes instead of SSH onlyLibravatar Sebastian Schuberth1-1/+1
This originates from an msysgit pull request, see: https://github.com/msysgit/git/pull/58 Signed-off-by: Eric Wieser <wieser.eric@gmail.com> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-03-26Merge branch 'jc/perl-cat-blob' into maintLibravatar Junio C Hamano1-10/+7
perl/Git.pm::cat_blob slurped everything in core only to write it out to a file descriptor, which was not a very smart thing to do. * jc/perl-cat-blob: Git.pm: fix cat_blob crashes on large files
2013-03-21Merge branch 'mn/send-email-works-with-credential'Libravatar Junio C Hamano1-21/+177
Hooks the credential system to send-email. * mn/send-email-works-with-credential: git-send-email: use git credential to obtain password Git.pm: add interface for git credential command Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipe Git.pm: refactor command_close_bidi_pipe to use _cmd_close Git.pm: fix example in command_close_bidi_pipe documentation Git.pm: allow command_close_bidi_pipe to be called as method
2013-03-21Merge branch 'jc/perl-cat-blob'Libravatar Junio C Hamano1-10/+7
perl/Git.pm::cat_blob slurped everything in core only to write it out to a file descriptor, which was not a very smart thing to do. * jc/perl-cat-blob: Git.pm: fix cat_blob crashes on large files
2013-03-08git svn: consistent spacing after "W:" in warningsLibravatar Eric Wong1-1/+1
All other instances of "W:"-prefixed warning messages have a space after the "W:" to help with readability. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-03-08git svn: ignore partial svn:mergeinfoLibravatar Jan Pešta1-0/+5
Currently this is cosmetic change - the merges are ignored, becuase the methods (lookup_svn_merge, find_rev_before, find_rev_after) are failing on comparing text with number. See http://www.open.collab.net/community/subversion/articles/merge-info.html Extract: The range r30430:30435 that was added to 1.5.x in this merge has a '*' suffix for 1.5.x\www. This '*' is the marker for a non-inheritable mergeinfo range. The '*' means that only the path on which the mergeinfo is explicitly set has had this range merged into it. Signed-off-by: Jan Pesta <jan.pesta@certicon.cz> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-02-27Git.pm: add interface for git credential commandLibravatar Michal Nazarewicz1-0/+151
Add a credential() function which is an interface to the git credential command. The code is heavily based on credential_* functions in <contrib/mw-to-git/git-remote-mediawiki>. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-22Git.pm: fix cat_blob crashes on large filesLibravatar Joshua Clayton1-10/+7
Read and write each 1024 byte buffer, rather than trying to buffer the entire content of the file. We are only copying the contents to a file descriptor and do not use it ourselves. Previous code would crash on all files > 2 Gib, when the offset variable became negative (perhaps below the level of perl), resulting in a crash. On a 32 bit system, or a system with low memory it might crash before reaching 2 GiB due to memory exhaustion. This code may leave a partial file behind in case of failure, where the old code would leave a completely empty file. Neither version verifies the correctness of the content. Calling code must take care of verification and cleanup. Signed-off-by: Joshua Clayton <stillcompiling@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-14Merge branch 'bw/get-tz-offset-perl'Libravatar Junio C Hamano3-12/+31
* bw/get-tz-offset-perl: cvsimport: format commit timestamp ourselves without using strftime perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases Move Git::SVN::get_tz to Git::get_tz_offset
2013-02-12Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipeLibravatar Michal Nazarewicz1-1/+14
The command_close_bidi_pipe() function will insist on closing both input and output pipes returned by command_bidi_pipe(). With this change it is possible to close one of the pipes in advance and pass undef as an argument. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-12Git.pm: refactor command_close_bidi_pipe to use _cmd_closeLibravatar Michal Nazarewicz1-19/+11
The body of the loop in command_close_bidi_pipe sub is identical to what _cmd_close sub does. Instead of duplicating, refactor _cmd_close so that it accepts a list of file handles to be closed, which makes it usable with command_close_bidi_pipe. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-09perl/Git.pm: fix get_tz_offset to properly handle DST boundary casesLibravatar Ben Walton1-3/+3
When passed a local time that was on the boundary of a DST change, get_tz_offset returned a GMT offset that was incorrect (off by one hour). This is because the time was converted to GMT and then back to a time stamp via timelocal() which cannot disambiguate boundary cases as noted in its documentation. Modify this algorithm, using an approach suggested in http://article.gmane.org/gmane.comp.version-control.git/213871 to first convert the timestamp in question to two broken down forms with localtime() and gmtime(), and then compute what timestamps these two broken down forms would represent in GMT (i.e. a timezone that does not have DST issues) by applying timegm() on them. The difference between the resulting timestamps is the timezone offset. This avoids the ambigious conversion and allows a correct time to be returned on every occassion. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-09Move Git::SVN::get_tz to Git::get_tz_offsetLibravatar Ben Walton3-12/+31
This function has utility outside of the SVN module for any routine that needs the equivalent of GNU strftime's %z formatting option. Move it to the top-level Git.pm so that non-SVN modules don't need to import the SVN module to use it. The rename makes the purpose of the function clearer. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07Git.pm: fix example in command_close_bidi_pipe documentationLibravatar Michal Nazarewicz1-1/+1
File handle goes as the first argument when calling print on it. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07Git.pm: allow command_close_bidi_pipe to be called as methodLibravatar Michal Nazarewicz1-1/+1
The documentation of command_close_bidi_pipe() claims that it can be called as a method, but it does not check whether the first argument is $self or not assuming the latter. Using _maybe_self() fixes this. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24git-svn: cleanup sprintf usage for uppercasing hexLibravatar Eric Wong2-3/+3
We do not need to call uc() separately for sprintf("%x") as sprintf("%X") is available. Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
2013-01-19git-svn: do not escape certain characters in pathsLibravatar Peter Wu1-1/+2
Subversion 1.7 and newer implement HTTPv2, an extension that should make HTTP more efficient. Servers with support for this protocol will make the subversion client library take an alternative code path that checks (with assertions) whether the URL is "canonical" or not. This patch fixes an issue I encountered while trying to `git svn dcommit` a rename action for a file containing a single quote character ("User's Manual" to "UserMan.tex"). It does not happen for older subversion 1.6 servers nor non-HTTP(S) protocols such as the native svn protocol, only on an Apache server shipping SVN 1.7. Trying to `git svn dcommit` under the aforementioned conditions yields the following error which aborts the commit process: Committing to http://example.com/svn ... perl: subversion/libsvn_subr/dirent_uri.c:1520: uri_skip_ancestor: Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed. error: git-svn died of signal 6 An analysis of the subversion source for the cause: - The assertion originates from uri_skip_ancestor which calls svn_uri_is_canonical, which fails when the URL contains percent-encoded values that do not necessarily have to be encoded (not "canonical" enough). This is done by a table lookup in libsvn_subr/path.c. Putting some debugging prints revealed that the character ' is indeed encoded to %27 which is not considered canonical. - url_skip_ancestor is called by svn_ra_neon__get_baseline_info with the root repository URL and path as parameters; - which is called by copy_resource (libsvn_ra_neon/commit.c) for a copy action (or in my case, renaming which is actually copy + delete old); - which is called by commit_add_dir; - which is assigned as a structure method "add_file" in svn_ra_neon__get_commit_editor. In the whole path, the path argument is not modified. Through some more uninteresting wrapper functions, the Perl bindings gives you access to the add_file method which will pass the path argument without modifications to svn. git-svn calls the "R"(ename) subroutine in Git::SVN::Editor which contains: 326 my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat, 327 $self->url_path($m->{file_a}), $self->{r}); "repo_path" basically returns the path as-is, unless the "svn.pathnameencoding" configuration property is set. "url_path" tries to escape some special characters, but does not take all special characters into account, thereby causing the path to contain some escaped characters which do not have to be escaped. The list of characters not to be escaped are taken from the subversion/libsvn_subr/path.c file to fully account for all characters. Tested with a filename containing all characters in the range 0x20 to 0x78 (inclusive). Signed-off-by: Peter Wu <lekensteyn@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-01-17git svn: do not overescape URLs (fallback case)Libravatar Jonathan Nieder1-1/+1
Subversion's canonical URLs are intended to make URL comparison easy and therefore have strict rules about what characters are special enough to urlencode and what characters should be left alone. When in the fallback codepath because unable to use libsvn's own canonicalization function for some reason, escape special characters in URIs according to the svn_uri__char_validity[] table in subversion/libsvn_subr/path.c (r935829). The libsvn versions that trigger this code path are not likely to be strict enough to care, but it's nicer to be consistent. Noticed by using SVN 1.6.17 perl bindings, which do not provide SVN::_Core::svn_uri_canonicalize (triggering the fallback code), with libsvn 1.7.5, whose do_switch is fussy enough to care: Committing to file:///home/jrn/src/git/t/trash%20directory.\ t9118-git-svn-funky-branch-names/svnrepo/pr%20ject/branches\ /more%20fun%20plugin%21 ... svn: E235000: In file '[...]/subversion/libsvn_subr/dirent_uri.c' \ line 2291: assertion failed (svn_uri_is_canonical(url, pool)) error: git-svn died of signal 6 not ok - 3 test dcommit to funky branch After this change, the '!' in 'more%20fun%20plugin!' is not urlencoded and t9118 passes again. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-01-17Git::SVN::Editor::T: pass $deletions to ->A and ->DLibravatar Jonathan Nieder1-2/+2
This shouldn't make a difference because the $deletions hash is only used when adding a directory (see 379862ec, 2012-02-20) but it's nice to be consistent to make reading smoother anyway. No functional change intended. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-12-17git-svn, perl/Git.pm: extend and use Git->prompt method for querying usersLibravatar Sven Strickroth2-20/+24
git-svn reads usernames and other user queries from an interactive terminal. This cause GUIs (w/o STDIN connected) to hang waiting forever for git-svn to complete (http://code.google.com/p/tortoisegit/issues/detail?id=967). This change extends the Git::prompt helper, so that it can also be used for non password queries, and makes use of it instead of using hand-rolled prompt-response code that only works with the interactive terminal. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-17perl/Git.pm: Honor SSH_ASKPASS as fallback if GIT_ASKPASS is not setLibravatar Sven Strickroth1-2/+5
If GIT_ASKPASS environment variable is not set, git-svn does not try to use SSH_ASKPASS as git-core does. This change adds a fallback to SSH_ASKPASS. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-17git-svn, perl/Git.pm: add central method for prompting passwordsLibravatar Sven Strickroth2-20/+45
git-svn reads passwords from an interactive terminal or by using GIT_ASKPASS helper tool. This cause GUIs (w/o STDIN connected) to hang waiting forever for git-svn to complete (http://code.google.com/p/tortoisegit/issues/detail?id=967). Commit 56a853b62c0ae7ebaad0a7a0a704f5ef561eb795 also tried to solve this issue, but was incomplete as described above. Instead of using hand-rolled prompt-response code that only works with the interactive terminal, a reusable prompt() method is introduced in this commit. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-10git svn: work around SVN 1.7 mishandling of svn:special changesLibravatar Jonathan Nieder1-1/+24
Subversion represents symlinks as ordinary files with content starting with "link " and the svn:special property set to "*". Thus a file can switch between being a symlink and a non-symlink simply by toggling its svn:special property, and new checkouts will automatically write a file of the appropriate type. Likewise, in subversion 1.6 and older, running "svn update" would notice changes in filetype and update the working copy appropriately. Starting in subversion 1.7 (issue 4091), changes to the svn:special property trip an assertion instead: $ svn up svn-tree Updating 'svn-tree': svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \ line 1583: assertion failed (action == svn_wc_conflict_action_edit \ || action == svn_wc_conflict_action_delete || action == \ svn_wc_conflict_action_replace) Revisions prepared with ordinary svn commands ("svn add" and not "svn propset") don't trip this because they represent these filetype changes using a replace operation, which is approximately equivalent to removal followed by adding a new file and works fine. Follow suit. Noticed using t9100. After this change, git-svn's file-to-symlink changes are sent in a format that modern "svn update" can handle and tests t9100.11-13 pass again. [ew: s,git-svn\.perl,perl/Git/SVN/Editor.pm,g] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn: keep leading slash when canonicalizing paths (fallback case)Libravatar Jonathan Nieder1-1/+0
Subversion's svn_dirent_canonicalize() and svn_path_canonicalize() APIs keep a leading slash in the return value if one was present on the argument, which can be useful since it allows relative and absolute paths to be distinguished. When git-svn's canonicalize_path() learned to use these functions if available, its semantics changed in the corresponding way. Some new callers rely on the leading slash --- for example, if the slash is stripped out then _canonicalize_url_ourselves() will transform "proto://host/path/to/resource" to "proto://hostpath/to/resource". Unfortunately the fallback _canonicalize_path_ourselves(), used when the appropriate SVN APIs are not usable, still follows the old semantics, so if that code path is exercised then it breaks. Fix it to follow the new convention. Noticed by forcing the fallback on and running tests. Without this patch, t9101.4 fails: Bad URL passed to RA layer: Unable to open an ra_local session to \ URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\ t9101-git-svn-props/svnrepo' contains unsupported hostname at \ /home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148 With it, the git-svn tests pass again. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05Git::SVN: rename private path fieldLibravatar Jonathan Nieder1-2/+2
All users of $gs->{path} should have been converted to use the accessor by now. Check our work by renaming the underlying variable to break callers that try to use it directly. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn: use path accessor for Git::SVN objectsLibravatar Eric Wong1-1/+1
The accessors should improve maintainability and enforce consistent access to Git::SVN objects. Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
2012-10-05Make git-svn branch patterns match complete URLLibravatar Ammon Riley1-1/+3
When using the {word,[...]} style of configuration for tags and branches, it appears the intent is to only match whole path parts, since the words in the {} pattern are meta-character quoted. When the pattern word appears in the beginning or middle of the url, it's matched completely, since the left side, pattern, and (non-empty) right side are joined together with path separators. However, when the pattern word appears at the end of the URL, the right side is an empty pattern, and the resulting regex matches more than just the specified pattern. For example, if you specify something along the lines of branches = branches/project/{release_1,release_2} and your repository also contains "branches/project/release_1_2", you will also get the release_1_2 branch. By restricting the match regex with anchors, this is avoided. Signed-off-by: Ammon Riley <ammon.riley@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn.perl: keep processing all commits in parents_excludeLibravatar Steven Walter1-1/+0
This fixes a bug where git finds the incorrect merge parent. Consider a repository with trunk, branch1 of trunk, and branch2 of branch1. Without this change, git interprets a merge of branch2 into trunk as a merge of branch1 into trunk. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Reviewed-by: Sam Vilain <sam@vilain.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tipLibravatar Steven Walter1-5/+3
Consider the case where you have trunk, branch1 of trunk, and branch2 of branch1. trunk is merged back into branch2, and then branch2 is reintegrated into trunk. The merge of branch2 into trunk will have svn:mergeinfo property references to both branch1 and branch2. When git-svn fetches the commit that merges branch2 (check_cherry_pick), it is necessary to eliminate the merged contents of branch1 as well as branch2, or else the merge will be incorrectly ignored as a cherry-pick. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Reviewed-by: Sam Vilain <sam@vilain.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-22Merge branch 'ms/git-svn-1.7'Libravatar Junio C Hamano5-109/+341
A series by Michael Schwern via Eric to update git-svn to revamp the way URLs are internally passed around, to make it work with SVN 1.7. * ms/git-svn-1.7: git-svn: remove ad-hoc canonicalizations git-svn: canonicalize newly-minted URLs git-svn: introduce add_path_to_url function git-svn: canonicalize earlier git-svn: replace URL escapes with canonicalization git-svn: attempt to mimic SVN 1.7 URL canonicalization t9107: fix typo t9118: workaround inconsistency between SVN versions Git::SVN{,::Ra}: canonicalize earlier git-svn: path canonicalization uses SVN API Git::SVN::Utils: remove irrelevant comment git-svn: add join_paths() to safely concatenate paths git-svn: factor out _collapse_dotdot function git-svn: use SVN 1.7 to canonicalize when possible git-svn: move canonicalization to Git::SVN::Utils use Git::SVN{,::RA}->url accessor globally use Git::SVN->path accessor globally Git::SVN::Ra: use accessor for URLs Git::SVN: use accessor for URLs internally Git::SVN: use accessors internally for path
2012-08-10git svn: reset invalidates the memoized mergeinfo cachesLibravatar Peter Baumann1-2/+25
Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30), git-svn has maintained some private per-repository caches in .git/svn/.caches to avoid refetching and recalculating some mergeinfo-related information with every 'git svn fetch'. This memoization can cause problems, e.g consider the following case: SVN repo: ... - a - b - c - m <- trunk \ / d - e <- branch1 The Git import of the above repo is at commit 'a' and doesn't know about the branch1. In case of an 'git svn rebase', only the trunk of the SVN repo is imported. During the creation of the git commit 'm', git svn uses the svn:mergeinfo property and tries to find the corresponding git commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase only imports the current branch so commit 'e' is not imported. Therefore git svn fails to create commit 'm' as a merge commit, because one of its parents is not known to git. The imported history looks like this: ... - a - b - c - m <- trunk A later 'git svn fetch' to import all branches can't rewrite the commit 'm' to add 'e' as a parent and to make it a real git merge commit, because it was already imported. That's why the imported history misses the merge and looks like this: ... - a - b - c - m <- trunk \ d - e <- branch1 Right now the only known workaround for importing 'm' as a merge is to force reimporting 'm' again from SVN, e.g. via $ git svn reset --revision $(git find-rev $c) $ git svn fetch Sadly, this is where the behavior has regressed: git svn reset doesn't invalidate the old mergeinfo cache, which is no longer valid for the reimport, which leads to 'm' beeing imprted with only 'c' as parent. As solution to this problem, this commit invalidates the mergeinfo cache to force correct recalculation of the parents. During development of this patch, several ways for invalidating the cache where considered. One of them is to use Memoize::flush_cache, which will call the CLEAR method on the underlying Memoize persistency implementation. Sadly, neither Memoize::Storable nor the newer Memoize::YAML module introduced in 68f532f4ba888 could optionally be used implement the CLEAR method, so this is not an option. Reseting the internal hash used to store the memoized values has the same problem, because it calls the non-existing CLEAR method of the underlying persistency layer, too. Considering this and taking into account the different implementations of the memoization modules, where Memoize::Storable is not in our control, implementing the missing CLEAR method is not an option, at least not if Memoize::Storable is still used. Therefore the easiest solution to clear the cache is to delete the files on disk in 'git svn reset'. Normally, deleting the files behind the back of the memoization module would be problematic, because the in-memory representation would still exist and contain wrong data. Fortunately, the memoization is active in memory only for a small portion of the code. Invalidating the cache by deleting the files on disk if it isn't active should be safe. Signed-off-by: Peter Baumann <waste.manager@gmx.de> Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: remove ad-hoc canonicalizationsLibravatar Michael G. Schwern1-1/+0
[ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: canonicalize newly-minted URLsLibravatar Michael G. Schwern2-6/+22
Go through all the spots that use the new add_path_to_url() to make a new URL and canonicalize them. * copyfrom_path has to be canonicalized else find_parent_branch will get confused * due to the `canonicalize_url($full_url) ne $full_url)` line of logic in gs_do_switch(), $full_url is left alone until after. At this point SVN 1.7 passes except for 3 tests in t9100-git-svn-basic.sh that look like an SVN bug to do with symlinks. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>