Thread (1 message) 1 message, 1 author, 2021-01-28

Re: [PATCH v4 3/3] clone: respect remote unborn HEAD

From: Junio C Hamano <hidden>
Date: 2021-01-28 05:51:08

Jeff King [off-list ref] writes:
... Afterwards, we
call it for the unborn HEAD (which I can buy is necessary) but _also_
for that regular path. I.e., why is the new code not:

  if (unborn_head_target && ...) {
          ref = unborn_head_target;
	  unborn_head_target = NULL;
	  create_symref("HEAD", ref, "");
  } else {
          branch = git_default_branch_name();
	  ref = xstrfmt("refs/heads/%s", branch);
  }

I.e., I don't understand:

  - why create_symref() wasn't need before (assuming it was not), and
    why it is OK to run it now in the non-unborn code path

  - why we need create_symref() in the unborn path (which is probably
    something mundane)

I can even buy the argument that it is simply for consistency, so that
all of the HEAD-setup commands are shared between the two paths. And
that it is OK to do so, because we are just overwriting what init-db did
before (even if sometimes it is the same thing). But I feel like that
deserves explanation in the commit message. :)
Yes, during yesterday's communication glitch, I also independently
was wondering about this and am dying to know if this is an
unrelated "fix", applicable even without the "unborn" support, or
breaking the non "unborn" side of the codepath.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help