Jeff King <peff@xxxxxxxx> 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.
