kernel/git - git - PowerEL Git System

28638 Commits

6 Branches

36 Tags

131 MiB

Tree: caae319e49

Commit Graph

Author	SHA1	Message	Date
Jeff King	c1921c184c	clone: always fetch remote HEAD In most cases, fetching the remote HEAD explicitly is unnecessary. It's just a symref pointing to a branch which we are already fetching, so we will already ask for its sha1. However, if the remote has a detached HEAD, things are less certain. We do not ask for HEAD's sha1, but we do try to write it into a local detached HEAD. In most cases this is fine, as the remote HEAD is pointing to some part of the history graph that we will fetch via the refs. But if the remote HEAD points to an "orphan" commit (one which was is not an ancestor of any refs), then we will not have the object, and update_ref will complain when we try to write the detached HEAD, aborting the whole clone. This patch makes clone always explicitly ask the remote for the sha1 of its HEAD commit. In the non-detached case, this is a no-op, as we were going to ask for that sha1 anyway. In the regular detached case, this will add an extra "want" to the protocol negotiation, but will not change the history that gets sent. And in the detached orphan case, we will fetch the orphaned history so that we can write it into our local detached HEAD. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jeff King	61adfd3097	consider only branches in guess_remote_head The guess_remote_head function tries to figure out where a remote's HEAD is pointing by comparing the sha1 of the remote's HEAD with the sha1 of various refs found on the remote. However, we were too liberal in matching refs, and would match tags or remote tracking branches, even though these things could not possibly be referenced by the HEAD symbolic ref (since git will detach when checking them out). As a result, a clone of a remote repository with a detached HEAD might write "refs/tags/*" into our local HEAD, which is bogus. The resulting HEAD should be detached. The other related code path is remote.c's get_head_names() (which is used for, among other things, "set-head -a"). This was not affected, however, as that function feeds only refs from refs/heads to guess_remote_head. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jeff King	3b368546a0	t: add tests for cloning remotes with detached HEAD We didn't test this setup at all, and doing so reveals a few bugs: 1. Cloning a repository with an orphaned detached HEAD (i.e., one that points to history that is not referenced by any ref) will fail. 2. Cloning a repository with a detached HEAD that points to a tag will cause us to write a bogus "refs/tags/..." ref into the HEAD symbolic ref. We should probably detach instead. 3. Cloning a repository with a detached HEAD that points to a branch will cause us to checkout that branch. This is a known limitation of the git protocol (we have to guess at HEAD's destination, since the symref contents aren't shown to us). This test serves to document the desired behavior, which can only be achieved once the git protocol learns to share symref information. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago

Author

SHA1

Message

Date

Jeff King

c1921c184c

clone: always fetch remote HEAD

In most cases, fetching the remote HEAD explicitly is
unnecessary. It's just a symref pointing to a branch which
we are already fetching, so we will already ask for its sha1.

However, if the remote has a detached HEAD, things are less
certain. We do not ask for HEAD's sha1, but we do try to
write it into a local detached HEAD. In most cases this is
fine, as the remote HEAD is pointing to some part of the
history graph that we will fetch via the refs.

But if the remote HEAD points to an "orphan" commit (one
which was is not an ancestor of any refs), then we will not
have the object, and update_ref will complain when we try to
write the detached HEAD, aborting the whole clone.

This patch makes clone always explicitly ask the remote for
the sha1 of its HEAD commit. In the non-detached case, this
is a no-op, as we were going to ask for that sha1 anyway. In
the regular detached case, this will add an extra "want" to
the protocol negotiation, but will not change the history
that gets sent. And in the detached orphan case, we will
fetch the orphaned history so that we can write it into our
local detached HEAD.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

14 years ago

Jeff King

61adfd3097

consider only branches in guess_remote_head

The guess_remote_head function tries to figure out where a
remote's HEAD is pointing by comparing the sha1 of the
remote's HEAD with the sha1 of various refs found on the
remote. However, we were too liberal in matching refs, and
would match tags or remote tracking branches, even though
these things could not possibly be referenced by the HEAD
symbolic ref (since git will detach when checking them out).

As a result, a clone of a remote repository with a detached
HEAD might write "refs/tags/*" into our local HEAD, which is
bogus. The resulting HEAD should be detached.

The other related code path is remote.c's get_head_names()
(which is used for, among other things, "set-head -a"). This was
not affected, however, as that function feeds only refs from
refs/heads to guess_remote_head.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

14 years ago

Jeff King

3b368546a0

t: add tests for cloning remotes with detached HEAD

We didn't test this setup at all, and doing so reveals a few
bugs:

  1. Cloning a repository with an orphaned detached HEAD
     (i.e., one that points to history that is not
     referenced by any ref) will fail.

  2. Cloning a repository with a detached HEAD that points
     to a tag will cause us to write a bogus "refs/tags/..."
     ref into the HEAD symbolic ref. We should probably
     detach instead.

  3. Cloning a repository with a detached HEAD that points
     to a branch will cause us to checkout that branch. This
     is a known limitation of the git protocol (we have to
     guess at HEAD's destination, since the symref contents
     aren't shown to us). This test serves to document the
     desired behavior, which can only be achieved once the
     git protocol learns to share symref information.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

14 years ago

3 Commits (caae319e49e236205d463de2ecf24ce5aae642ab)