[PATCH 0/3] cloning unborn HEAD when other branches are present
- From
Jeff King <peff@peff.net>
- Date
- Jul 6, 2022, 07:57 UTC
- Message-ID
- <YsVAfudoUA5YkQWH@coredump.intra.peff.net>
I ran across a situation today where I was being a little clever with manipulating branches, and the results were confusing. Basically I have an old bare server-side repo with a "master" branch, and realized that I wanted to start a new line of history, but save the old one for historical purposes. So I did this in the bare repo:
cd bare.git git branch -m master old-history git symbolic-ref HEAD new-history
to move the old one and point HEAD at the new unborn branch. Note that I didn't just name it "master"; now that there are two lines of history, I gave them identifiable and distinct names.
My intent was to then clone and create the new history:
git clone bare.git local-repo cd local-repo git commit [etc] git push
I assumed that just like in the empty-repo case, the clone would start on "new-history". But it doesn't! This series fixes it.
+cc Jonathan Tan. Definitely not your bug, as the behavior has been this way forever. But this is very adjacent to your empty-repo unborn head work from 4f37d45706 (clone: respect remote unborn HEAD, 2021-02-05), and I think harmonizing a related case.
[1/3]: clone: drop extra newline from warning message [2/3]: clone: factor out unborn head setup into its own function [3/3]: clone: propagate empty remote HEAD even with other branches
builtin/clone.c | 49 ++++++++++++++++++++++++------------------ t/t5702-protocol-v2.sh | 38 ++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+), 21 deletions(-)
-Peff