On Fri, Jun 26, 2020 at 02:07:37PM -0700, Junio C Hamano wrote: > > $ 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. Given the difficulties many users seem to have with understanding detached HEADs, I think that might be even more unfriendly. :) > > 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. Yeah, agreed. -Peff
