[0/3] cloning unborn HEAD when other branches are present

Message

Jeff King July 6, 2022, 7:57 a.m. UTC

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

Comments

Jonathan Tan July 6, 2022, 6:17 p.m. UTC | #1

Jeff King <[e-mail]> writes:
> +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.

Thanks for the patch. Indeed, this is a similar problem, and worth
fixing in the same way.

Reviewed-by: Jonathan Tan <[e-mail]>