t5505: fix "set-head --auto with ambiguous HEAD" test

When two or more branches point at the same commit and HEAD is
pointing at one of them, without the symref extension, there is no
way to remotely tell which one of these branches HEAD points at.
The test in question attempts to make sure that this situation is
diagnosed and results in a failure.

However, even if there _were_ a way to reliably tell which branch
the HEAD points at, "set-head --auto" would fail if there is no
remote tracking branch.  Make sure that this test does not fail
for that "wrong" reason.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack.c: do not pass confusing cb_data to mark_our_ref()

The callee does not use cb_data, and the caller is an intermediate
function in a callchain that later wants to use the cb_data for its
own use.  Clarify the code by breaking the dataflow explicitly by
not passing cb_data down to mark_our_ref().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack: send symbolic ref information as capability

One long-standing flaw in the pack transfer protocol was that there
was no way to tell the other end which branch "HEAD" points at.
With a capability "symref=HEAD:refs/heads/master", let the sender to
tell the receiver what symbolic ref points at what ref.

This capability can be repeated more than once to represent symbolic
refs other than HEAD, such as "refs/remotes/origin/HEAD").

Add an infrastructure to collect symbolic refs, format them as extra
capabilities and put it on the wire.  For now, just send information
on the "HEAD" and nothing else.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack: send non-HEAD symbolic refs

With the same mechanism as used to tell where "HEAD" points at to
the other end, we can tell the target of other symbolic refs as
well.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
connect.c: make parse_feature_value() static

Signed-off-by: Junio C Hamano <gitster@pobox.com>
connect: annotate refs with their symref information in get_remote_head()

By doing this, clients of upload-pack can now reliably tell what ref
a symbolic ref points at; the updated test in t5505 used to expect
failure due to the ambiguity and made sure we give diagnostics, but
we no longer need to be so pessimistic. Make sure we correctly learn
which branch HEAD points at from the other side instead.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone: test the new HEAD detection logic

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: fix signed commit parsing

When parsing a commit object, git-svn wrongly think that a line
containing spaces means the end of headers and the start of the commit
message. In case of signed commit, the gpgsig entry contains a line with
one space, so "git svn dcommit" will include part of the signature in
the commit message.

An example of such problem :
http://svnweb.mageia.org/treasurer?view=revision&revision=86

This commit changes the regex to only match an empty line as separator
between the headers and the commit message.

Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn.txt: fix AsciiDoc formatting error

As asterisks are used to indicate bold text in AsciiDoc, shell glob
expressions must be escaped appropriately.

Signed-off-by: Keshav Kini <keshav.kini@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn.txt: reword description of gc command

It's redundant to say that $GIT_DIR/svn/<refname>/unhandled.log or
$GIT_DIR/svn/<refname>/index is in .git/svn when $GIT_DIR is '.git', and
is wrong when $GIT_DIR is not '.git'

Also, a '/' was missing from the pathname $GIT_DIR/svn/<refname>/index .

Signed-off-by: Keshav Kini <keshav.kini@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn.txt: replace .git with $GIT_DIR

As $GIT_DIR may not equal '.git', it's usually more generally correct to
refer to files in $GIT_DIR rather than in .git .

This will also allow me to link some of the occurrences of '.git' in
git-svn.txt to a new reference target inside this file in an upcoming
commit, because in AsciiDoc definitions apparently can't start with
a '.' character.

Signed-off-by: Keshav Kini <keshav.kini@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn.txt: elaborate on rev_map files

The man page for `git svn` describes a situation in which "'git svn'
will not be able to rebuild" your $GIT_DIR/svn/**/.rev_map* files, but
no mention is made of in what circumstances `git svn` *will* be able to
do so, how to get `git svn` to do so, or even what these files are.

This patch adds a FILES section to the man page with a description of
what $GIT_DIR/svn/**/.rev_map* files are and how they are (re)built, and
links to this description from various other parts of the man page.

Signed-off-by: Keshav Kini <keshav.kini@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Documentation/git-svn: Promote the use of --prefix in docs + examples

Currently, the git-svn defaults to using an empty prefix, which ends
up placing the SVN-tracking refs directly in refs/remotes/*. This
placement runs counter to Git's convention of placing remote-tracking
branches in refs/remotes/$remote/*.

Furthermore, combining git-svn with "regular" Git remotes run the risk
of clobbering refs under refs/remotes (e.g. if you have a git remote
called "tags" with a "v1" branch, it will overlap with the git-svn's
tracking branch for the "v1" tag from Subversion.

Even though the git-svn refs stored in refs/remotes/* are not "proper"
remote-tracking branches (since they are not covered by a proper git
remote's refspec), they clearly represent a similar concept, and would
benefit from following the same convention.

For example, if git-svn tracks Subversion branch "foo" at
refs/remotes/foo, and you create a local branch refs/heads/foo to add
some commits to be pushed back to Subversion (using "git svn dcommit),
then it is clearly unhelpful of Git to throw

  warning: refname 'foo' is ambiguous.

every time you checkout, rebase, or otherwise interact with the branch.

At this time, the user is better off using the --prefix=foo/ (the
trailing slash is important) to git svn init/clone, to cause the
SVN-tracking refs to be placed at refs/remotes/foo/* instead of
refs/remotes/*. This patch updates the documentation to encourage
use of --prefix.

This is also in preparation for changing the default value of --prefix
at some point in the future.

Cc: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn: Warn about changing default for --prefix in Git v2.0

In Git v2.0, we will change the default --prefix for init/clone from
none/empty to "origin/" (which causes SVN-tracking branches to be
placed at refs/remotes/origin/* instead of refs/remotes/*).

This patch warns users about the upcoming change, both in the git-svn
manual page, and on stderr when running init/clone in the "multi-mode"
without providing a --prefix.

Cc: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
revision: do not peel tags used in range notation

A range notation "A..B" means exactly the same thing as what "^A B"
means, i.e. the set of commits that are reachable from B but not
from A.  But the internal representation after the revision parser
parsed these two notations are subtly different.

 - "rev-list ^A B" leaves A and B in the revs->pending.objects[]
   array, with the former marked as UNINTERESTING and the revision
   traversal machinery propagates the mark to underlying commit
   objects A^0 and B^0.

 - "rev-list A..B" peels tags and leaves A^0 (marked as
   UNINTERESTING) and B^0 in revs->pending.objects[] array before
   the traversal machinery kicks in.

This difference usually does not matter, but starts to matter when
the --objects option is used.  For example, we see this:

    $ git rev-list --objects v1.8.4^1..v1.8.4 | grep $(git rev-parse v1.8.4)
    $ git rev-list --objects v1.8.4 ^v1.8.4^1 | grep $(git rev-parse v1.8.4)
    04f013dc38d7512eadb915eba22efc414f18b869 v1.8.4

With the former invocation, the revision traversal machinery never
hears about the tag v1.8.4 (it only sees the result of peeling it,
i.e. the commit v1.8.4^0), and the tag itself does not appear in the
output.  The latter does send the tag object itself to the output.

Make the range notation keep the unpeeled objects and feed them to
the traversal machinery to fix this inconsistency.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge git://git.bogomips.org/git-svn

* git://git.bogomips.org/git-svn:
  git-svn: Warn about changing default for --prefix in Git v2.0
  Documentation/git-svn: Promote the use of --prefix in docs + examples
  git-svn.txt: elaborate on rev_map files
  git-svn.txt: replace .git with $GIT_DIR
  git-svn.txt: reword description of gc command
  git-svn.txt: fix AsciiDoc formatting error
  git-svn: fix signed commit parsing
http: use curl's tcp keepalive if available

Commit a15d069 taught git to use curl's SOCKOPTFUNCTION hook
to turn on TCP keepalives. However, modern versions of curl
have a TCP_KEEPALIVE option, which can do this for us. As an
added bonus, the curl code knows how to turn on keepalive
for a much wider variety of platforms. The only downside to
using this option is that not everybody has a new enough curl.
Let's split our keepalive options into three conditionals:

  1. With curl 7.25.0 and newer, we rely on curl to do it
     right.

  2. With older curl that still knows SOCKOPTFUNCTION, we
     use the code from a15d069.

  3. Otherwise, we are out of luck, and the call is a no-op.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update draft release notes to 1.8.5

List notable topics that graduated during Jonathan's interim
maintainership.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'ew/keepalive' into next

* ew/keepalive:
  http: use curl's tcp keepalive if available
Merge branch 'jc/upload-pack-send-symref' into next

One long-standing flaw in the pack transfer protocol used by "git
clone" was that there was no way to tell the other end which branch
"HEAD" points at, and the receiving end needed to guess.  A new
capability has been defined in the pack protocol to convey this
information so that cloning from a repository with more than one
branches pointing at the same commit where the HEAD is at now
reliably sets the initial branch in the resulting repository.

* jc/upload-pack-send-symref:
  clone: test the new HEAD detection logic
  connect: annotate refs with their symref information in get_remote_head()
  connect.c: make parse_feature_value() static
  upload-pack: send non-HEAD symbolic refs
  upload-pack: send symbolic ref information as capability
  upload-pack.c: do not pass confusing cb_data to mark_our_ref()
  t5505: fix "set-head --auto with ambiguous HEAD" test