Re: Regarding Git and Branch Naming

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> We definitely _could_ extend HEAD to allow a "not pointing at anything"
> state. Presumably for reading that would behave like the "pointing at a
> branch that doesn't exist yet" case. But I think the experience it
> creates for writing is not very good. I.e., I think the best we could do
> is something like:
>
>   $ git init
>   $ git add some-files
>   $ git commit -m whatever
>   fatal: HEAD does not point to any branch
>   hint: use "git checkout -b <branch>" to make commits on <branch>

... or you could stay forever on detached HEAD state.

Very briefly in early days of Git, the envisioned use case (which
quickly was retracted) was to use one repository per one line of
development (so you'd pull among the repositories you have, and each
repository does not even need to have "the default" branch---there
was no need for any branch).  Staying forever on detached HEAD is
pretty much in line with that.

> Perhaps that's not _too_ bad, but it feels a bit unfriendly (and
> definitely more likely to cause backwards compatibility issues than
> picking _some_ default name). There would also be a lot of corner cases
> to cover and debug (e.g., "git checkout foo" moving away from the "no
> branch" state should make the usual complaints if we'd have to overwrite
> or modify index and untracked files).

I do not see much point in adding such a new set-up, only to risk
introducing unexpected and unnecessary bugs.  Such extra engineering
resource is better spent elsewhere, I would say.