This is another approach to the same problem that a repository cloned from
another repository whose default branch is not 'master' can use 'master'
as the default.
The current code has to guess where the HEAD in the original repository
points at, because the original protocol tells what object each ref points
at but does not talk about which other ref a symbolic ref points at. The
implication of this is that if you prepare another branch that points at
your master, like this:
$ git checkout -b another master
and keep that other branch checked out (and in sync with 'master'), a
clone made from such a repository may incorrectly have its HEAD pointing
at 'master', not 'another'.
Instead of introducing a full-fledged protocol extension, this round hides
the new information in the same place as the server capabilities list that
is used to implement protocol extension is hidden from older clients.
This way, it does not have to work around the code structure imposed by
the transport API, does not have to introduce an extra round trip, and
does not have to trigger an annoying (but harmless) error message when an
older client contacts a new uploader.
[1/6] get_remote_heads(): refactor code to read "server capabilities"
[2/6] connect.c::read_extra_info(): prepare to receive more than server
capabilities
[3/6] connect.c::read_extra_info(): find where HEAD points at
[4/6] clone: find the current branch more explicitly
[5/6] upload-pack: send the HEAD information
[6/6] clone: test the new HEAD detection logic
The first four are the client side, the fifth one is the uploader side,
and the last one is the test. After storing these patches in separate
files, you would build this history (on top of 'master'):
git am 1 2 3 4
git reset --hard HEAD~4 5---------------M---6
git am 5 / /
git merge HEAD@{2} ---1---2---3---4
git am 6
builtin-clone.c | 24 +++++++++++++++++++-----
connect.c | 47 +++++++++++++++++++++++++++++++++++++++++++----
t/t5601-clone.sh | 11 +++++++++++
upload-pack.c | 14 +++++++++++---
4 files changed, 84 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
