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
