Craig H MaynardAll,
Does the git init command really need to create a default branch? Perhaps that step could be left to the user.
Craig
-- Craig H Maynard Rhode Island, USA
threads / discuss / 53761
Re: Regarding Git and Branch Naming
Subject: Re: Regarding Git and Branch Naming
Craig H Maynard
Chris TorekOn Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard <chmaynard@me.com> wrote:
> Does the git init command really need to create a default branch? Perhaps that step could be left to the user.
The HEAD pseudo-ref must exist and must contain a valid OID or branch name. (If it does not exist, Git says that the directory is not a repository. Perhaps this test could be weakened, but that's definitely a fairly big change.)
In a new, empty repository there are no valid OIDs, so HEAD must contain a branch name. The branch itself need not exist, but whatever name is in HEAD is the branch that will be created when the user makes the first commit.
Chris
Jeff KingOn Fri, Jun 26, 2020 at 11:33:53AM -0700, Chris Torek wrote:
Show 12 quoted lines
> On Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard <chmaynard@me.com> wrote: > > Does the git init command really need to create a default branch? Perhaps that step could be left to the user. > > The HEAD pseudo-ref must exist and must contain a valid OID or > branch name. (If it does not exist, Git says that the directory > is not a repository. Perhaps this test could be weakened, but > that's definitely a fairly big change.) > > In a new, empty repository there are no valid OIDs, so HEAD must > contain a branch name. The branch itself need not exist, but > whatever name is in HEAD is the branch that will be created > when the user makes the first commit.
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>
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).
-Peff
Junio C HamanoJeff King <peff@peff.net> writes:
Show 11 quoted lines
> 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.
Show 6 quoted lines
> 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.
Jeff KingOn Fri, Jun 26, 2020 at 02:07:37PM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> > $ 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. :)
Show 10 quoted lines
> > 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
Philip OakleyOn 26/06/2020 21:35, Jeff King wrote:
Show 33 quoted lines
> On Fri, Jun 26, 2020 at 11:33:53AM -0700, Chris Torek wrote: > >> On Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard <chmaynard@me.com> wrote: >>> Does the git init command really need to create a default branch? Perhaps that step could be left to the user. >> The HEAD pseudo-ref must exist and must contain a valid OID or >> branch name. (If it does not exist, Git says that the directory >> is not a repository. Perhaps this test could be weakened, but >> that's definitely a fairly big change.) >> >> In a new, empty repository there are no valid OIDs, so HEAD must >> contain a branch name. The branch itself need not exist, but >> whatever name is in HEAD is the branch that will be created >> when the user makes the first commit. > 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> > > 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). > >
A wild bikeshed question: Is HEAD itself protected as a branch name e.g. that HEAD could contain `ref: HEAD` or `ref: refs/heads/HEAD`? (or maybe the null oid
It sort of feels that we may already have some sort of protection for the first self reference - i.e. exists, but not defined (self-reference).
Philip
Jeff KingOn Fri, Jun 26, 2020 at 10:33:14PM +0100, Philip Oakley wrote:
> A wild bikeshed question: Is HEAD itself protected as a branch name e.g. > that HEAD could contain `ref: HEAD` or `ref: refs/heads/HEAD`? (or maybe > the null oid
The first is not legal; we insist that symrefs start with "refs/". The second one _is_ legal, but isn't any kind of loop. The HEAD symref is .git/HEAD, which is distinct from a ref of the same name inside refs/heads/.
It's confusing, of course, because the lookup rules make it hard to refer to refs/heads/HEAD. For that reason we do disallow it from the branch-creation porcelains like git-branch and git-checkout.
-Peff
Elijah NewrenOn Fri, Jun 26, 2020 at 1:39 PM Jeff King <peff@peff.net> wrote:
Show 36 quoted lines
> > On Fri, Jun 26, 2020 at 11:33:53AM -0700, Chris Torek wrote: > > > On Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard <chmaynard@me.com> wrote: > > > Does the git init command really need to create a default branch? Perhaps that step could be left to the user. > > > > The HEAD pseudo-ref must exist and must contain a valid OID or > > branch name. (If it does not exist, Git says that the directory > > is not a repository. Perhaps this test could be weakened, but > > that's definitely a fairly big change.) > > > > In a new, empty repository there are no valid OIDs, so HEAD must > > contain a branch name. The branch itself need not exist, but > > whatever name is in HEAD is the branch that will be created > > when the user makes the first commit. > > 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> > > 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). > > -Peff
The error doesn't need to come that late; it could come at the "init" step when no branch name is specified. If that's desirable, a necessary first step towards that would be making a plain "git init" throw a warning that we are creating a repo with a default branch name of <whatever> since the user didn't specify one.
Of course, we could decide to only take that first step and never escalate it to an error. It'd still leave us with some default name, but would de-emphasize it some.
Not sure if I'm in favor of either of these ideas or not, but just thought I'd point out alternate possibilities towards removing/de-emphasizing the default initial branch name.
Elijah
Jeff KingOn Fri, Jun 26, 2020 at 02:58:17PM -0700, Elijah Newren wrote:
Show 13 quoted lines
> The error doesn't need to come that late; it could come at the "init" > step when no branch name is specified. If that's desirable, a > necessary first step towards that would be making a plain "git init" > throw a warning that we are creating a repo with a default branch name > of <whatever> since the user didn't specify one. > > Of course, we could decide to only take that first step and never > escalate it to an error. It'd still leave us with some default name, > but would de-emphasize it some. > > Not sure if I'm in favor of either of these ideas or not, but just > thought I'd point out alternate possibilities towards > removing/de-emphasizing the default initial branch name.
Yeah, I agree those are all possible options. My issue is that not picking a default means the user is forced to do so before continuing, which seems fundamentally unfriendly to me. It's putting more friction between the user and their goal.
The warning version doesn't force that choice, but then I don't think that's it really accomplished that much. We've still got to have a default, and now we have an annoying warning on top. :)
-Peff