Re: Regarding Git and Branch Naming

> >   $ 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.