git/perl, branch v2.8.2

git-svn: shorten glob error message

2016-03-15T01:35:39Z

Error messages should attempt to fit within the confines of an 80-column terminal to avoid compatibility and accessibility problems. Furthermore the word "directories" can be misleading when used in the context of git refnames. Signed-off-by: Eric Wong

git-svn: loosen config globs limitations

2016-03-15T01:35:38Z

Expand the area of globs applicability for branches and tags in git-svn. It is now possible to use globs like 'a*e', or 'release_*'. This allows users to avoid long lines in config like: branches = branches/{release_20,release_21,release_22,...} In favor of: branches = branches/release_* [ew: amended commit message, minor formatting and style fixes] Signed-off-by: Victor Leschuk Signed-off-by: Eric Wong

git-svn: apply "svn.pathnameencoding" before URL encoding

2016-02-22T02:29:36Z

The conversion from "svn.pathnameencoding" to UTF-8 should be applied first, and then URL encoding should be applied on the resulting UTF-8 path. The reversed order of these transforms (used before this fix) makes non-UTF-8 URL which causes error from Subversion such as "Filesystem has no item: '...' path not found" when sending a rename (or a copy) from non-ASCII path. [ew: t9115 test case added (requires SVN_HTTPD_PORT set to test), squash LC_ALL=$a_utf8_locale export from Kazutoshi for Cygwin] Signed-off-by: Kazutoshi SATODA Signed-off-by: Eric Wong

git-svn: enable "svn.pathnameencoding" on dcommit

2016-02-22T02:28:34Z

Without the initialization of $self->{pathnameencoding}, conversion in repo_path() is always skipped as $self->{pathnameencoding} is undefined even if "svn.pathnameencoding" is configured. The lack of conversion results in mysterious failure of dcommit (e.g. "Malformed XML") which happen only when a commit involves a change on non-ASCII path. [ew: add test case to t9115, squash LC_ALL=$a_utf8_locale export from Kazutoshi for Cygwin] Signed-off-by: Kazutoshi SATODA Signed-off-by: Eric Wong

Merge branch 'js/mingw-tests'

2016-02-17T18:13:29Z

Test scripts have been updated to remove assumptions that are not portable between Git for POSIX and Git for Windows, or to skip ones with expectations that are not satisfiable on Git for Windows. * js/mingw-tests: (21 commits) gitignore: ignore generated test-fake-ssh executable mingw: do not bother to test funny file names mingw: skip a test in t9130 that cannot pass on Windows mingw: handle the missing POSIXPERM prereq in t9124 mingw: avoid illegal filename in t9118 mingw: mark t9100's test cases with appropriate prereqs t0008: avoid absolute path mingw: work around pwd issues in the tests mingw: fix t9700's assumption about directory separators mingw: skip test in t1508 that fails due to path conversion tests: turn off git-daemon tests if FIFOs are not available mingw: disable mkfifo-based tests mingw: accomodate t0060-path-utils for MSYS2 mingw: fix t5601-clone.sh mingw: let lstat() fail with errno == ENOTDIR when appropriate mingw: try to delete target directory before renaming mingw: prepare the TMPDIR environment variable for shell scripts mingw: factor out Windows specific environment setup Git.pm: stop assuming that absolute paths start with a slash mingw: do not trust MSYS2's MinGW gettext.sh ...

Merge branch 'ew/svn-1.9.0-auth'

2016-02-01T23:14:23Z

* ew/svn-1.9.0-auth: git-svn: fix auth parameter handling on SVN 1.9.0+

git-svn: fix auth parameter handling on SVN 1.9.0+

2016-01-27T06:30:02Z

For users with "store-passwords = no" set in the "[auth]" section of their ~/.subversion/config, SVN 1.9.0+ would fail with the following message when attempting to call svn_auth_set_parameter: Value is not a string (or undef) at Git/SVN/Ra.pm Ironically, this breakage was caused by r1553823 in subversion: "Make svn_auth_set_parameter() usable from Perl bindings." Since 2007 (602015e0e6ec), git-svn has used a workaround to make svn_auth_set_parameter usable internally. However this workaround breaks under SVN 1.9+, which deals properly with the type mapping and fails to recognize our workaround. For pre-1.9.0 SVN, we continue to use the existing workaround for the lack of proper type mapping in the bindings. Tested under subversion 1.6.17 and 1.9.3. I've also verified r1553823 was not backported to SVN 1.8.x: BRANCH=http://svn.apache.org/repos/asf/subversion/branches/1.8.x svn log -v $BRANCH/subversion/bindings/swig/core.i ref: https://bugs.debian.org/797705 Cc: 797705@bugs.debian.org Reported-by: Thierry Vignaud Signed-off-by: Eric Wong Tested-by: Thierry Vignaud Signed-off-by: Junio C Hamano

Git.pm: stop assuming that absolute paths start with a slash

2016-01-26T21:42:59Z

On Windows, absolute paths never start with a slash, unless a POSIX emulation layer is used. The latter is the case for MSYS2's Perl that Git for Windows leverages. However, in the tests we also go through plain `git.exe`, which does *not* leverage the POSIX emulation layer, and therefore the paths we pass to Perl may actually be DOS-style paths such as C:/Program Files/Git. So let's just use Perl's own way to test whether a given path is absolute or not instead of home-brewing our own. This patch partially fixes t7800 and t9700 when running in Git for Windows' SDK. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

git-svn: improve rebase/mkdirs performance

2015-11-10T01:35:01Z

Processing empty_dir directives becomes extremely slow for svn repositories with a large enough history. This is due to using a single hash to store the list of empty directories, with the expensive step being purging items from that hash using grep+delete. Storing directories in a hash of hashes improves the performance of this purge step and removes a potentially lengthy delay after every rebase/mkdirs command. The svn repository with this behaviour has 110K commits with unhandled.log containing 170K empty_dir directives. This takes 10 minutes to process when using a single hash, vs 3 seconds with a hash of hashes. Signed-off-by: Dair Grant Signed-off-by: Eric Wong

send-email: reduce dependencies impact on parse_address_line

2015-07-07T21:38:20Z

parse_address_line had not the same behavior whether the user had Mail::Address or not. Teach parse_address_line to behave like Mail::Address. When the user input is correct, this implementation behaves exactly like Mail::Address except when there are quotes inside the name: "Jane Do"e In this case the result of parse_address_line is: With M::A : "Jane Do" e Without : "Jane Do e" When the user input is not correct, the behavior is also mostly the same. Unlike Mail::Address, this doesn't parse groups and recursive commentaries. Signed-off-by: Remi Lespinet Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano