* 'master' of git://github.com/vnwildman/git:
  l10n: vi.po: update translation upto cc76011e

* translate all new messages (100%)
* review some others
Signed-off-by: NTran Ngoc Quan <vnwildman@gmail.com>

* maint:
  Fix spelling error in post-receive-email hook

Signed-off-by: NRichard Fearn <richardfearn@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  gitweb.cgi: fix "comitter_tz" typo in feed

gitweb's feeds sometimes contained committer timestamps in the wrong timezone
due to a misspelling.
Signed-off-by: NDylan Simon <dylan@dylex.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* rr/git-uri-doc:
  Git url doc: mark ftp/ftps as read-only and deprecate them

* bw/cp-a-is-gnuism:
  tests: "cp -a" is a GNUism

* nd/doc-ignore:
  gitignore.txt: suggestions how to get literal # or ! at the beginning

* jc/doc-long-options:
  gitcli: parse-options lets you omit tail of long options

* maint:
  attr: a note about the order of .gitattributes lookup

* git://bogomips.org/git-svn:
  svn test: escape peg revision separator using empty peg rev
  git svn: work around SVN 1.7 mishandling of svn:special changes

This test script uses "svn cp" to create a branch with an @-sign in
its name:

	svn cp "pr ject/trunk" "pr ject/branches/not-a@{0}reflog"

That sets up for later tests that fetch the branch and check that git
svn mangles the refname appropriately.

Unfortunately, modern svn versions interpret path arguments with an
@-sign as an example of path@revision syntax (which pegs a path to a
particular revision) and truncate the path or error out with message
"svn: E205000: Syntax error parsing peg revision '{0}reflog'".

When using subversion 1.6.x, escaping the @ sign as %40 avoids trouble
(see 08fd28bb, 2010-07-08).  Newer versions are stricter:

	$ svn cp "$repo/pr ject/trunk" "$repo/pr ject/branches/not-a%40{reflog}"
	svn: E205000: Syntax error parsing peg revision '%7B0%7Dreflog'

The recommended method for escaping a literal @ sign in a path passed
to subversion is to add an empty peg revision at the end of the path
("branches/not-a@{0}reflog@").  Do that.

Pre-1.6.12 versions of Subversion probably treat the trailing @ as
another literal @-sign (svn issue 3651).  Luckily ever since
v1.8.0-rc0~155^2~7 (t9118: workaround inconsistency between SVN
versions, 2012-07-28) the test can survive that.

Tested with Debian Subversion 1.6.12dfsg-6 and 1.7.5-1 and r1395837
of Subversion trunk (1.8.x).
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Tested-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

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: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK
variable, either from the environment or command line of an
'make test' invocation. In order to allow the malloc checks to be
disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK
to the environment using an export directive.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is the documentation part of

1a9d7e9b (attr.c: read .gitattributes from index as well. - 2007-08-14)
06f33c17 (Read attributes from the index that is being checked out - 2009-03-13)
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  l10n: de.po: fix a few minor typos

40bfbde9 ("build: don't duplicate substitution of make variables",
2012-09-11) by mistake removed a necessary comma at the end of
"CC_LD_DYNPATH=-Wl,rpath," in line 414.

When executing "./configure --with-zlib=PATH", this resulted in

      [...]
      CC xdiff/xhistogram.o
      AR xdiff/lib.a
      LINK git-credential-store
  /usr/bin/ld: bad -rpath option
  collect2: ld returned 1 exit status
  make: *** [git-credential-store] Error 1
  $

during make.
Signed-off-by: NØyvind A. Holm <sunny@sunbase.org>
Acked-by: NStefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'maint' of git://github.com/git-l10n/git-po:
  l10n: de.po: fix a few minor typos

These tests just want a bit-for-bit identical copy; they do not need
even -H (there is no symbolic link involved) nor -p (there is no
funny permission or ownership issues involved).

Just use "cp -R" instead.
Signed-off-by: NBen Walton <bdwalton@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is not even worth mentioning their removal; just discourage
people from using them.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The fsck test assumed too much on what kind of error it will
detect. The only important thing is the inconsistency is detected
as an error.

* jc/maint-t1450-fsck-order-fix:
  t1450: the order the objects are checked is undefined

"git fmt-merge-msg" (an internal helper reduce_heads() it uses) had
a severe performance regression; an empty "git pull" took forever to
finish as the result.

* jc/merge-bases-paint-fix:
  paint_down_to_common(): parse commit before relying on its timestamp

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git status" honored the ignore=dirty settings in .gitmodules but
"git commit" didn't.

* os/commit-submodule-ignore:
  commit: pay attention to submodule.$name.ignore in .gitmodules

"git receive-pack" (the counterpart to "git push") did not give
progress output while processing objects it received to the puser
when run over the smart-http protocol.

* jk/receive-pack-unpack-error-to-pusher:
  receive-pack: drop "n/a" on unpacker errors
  receive-pack: send pack-processing stderr over sideband
  receive-pack: redirect unpack-objects stdout to /dev/null

A repository created with "git clone --single" had its fetch
refspecs set up just like a clone without "--single", leading the
subsequent "git fetch" to slurp all the other branches, defeating
the whole point of specifying "only this branch".

* rt/maint-clone-single:
  clone --single: limit the fetch refspec to fetched branch

It was unclear in the documentation for "git blame" that it is
unnecessary for users to use the "--follow" option.

* jc/blame-follows-renames:
  git blame: document that it always follows origin across whole-file renames

A patch attached as application/octet-stream (e.g. not text/*) were
mishandled, not correctly honoring Content-Transfer-Encoding
(e.g. base64).

* lt/mailinfo-handle-attachment-more-sanely:
  mailinfo: don't require "text" mime type for attachments

We support backslash escape, but we hide the details behind the phrase
"a shell glob suitable for consumption by fnmatch(3)". So it may not
be obvious how one can get literal # or ! at the beginning of pattern.
Add a few lines on how to work around the magic characters.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

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: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

The accessors should improve maintainability and enforce
consistent access to Git::SVN objects.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>

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: NAmmon Riley <ammon.riley@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

This fixes `ambiguous redirect' error given by bash.

[ew: fix misspelled test name,
     also eliminate space after ">>" to conform to guidelines]
Signed-off-by: NEric Wong <normalperson@yhbt.net>

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: NSteven Walter <stevenrwalter@gmail.com>
Reviewed-by: NSam Vilain <sam@vilain.net>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

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: NSteven Walter <stevenrwalter@gmail.com>
Reviewed-by: NSam Vilain <sam@vilain.net>
Signed-off-by: NEric Wong <normalperson@yhbt.net>