Re: Regarding Git and Branch Naming

Re: Regarding Git and Branch Naming

[Craig H Maynard]

All,

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

Re: Regarding Git and Branch Naming

[Chris Torek]

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.

Chris

Re: Regarding Git and Branch Naming

[Jeff King]

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

Re: Regarding Git and Branch Naming

[Junio C Hamano]

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.

Re: Regarding Git and Branch Naming

[Philip Oakley]

On 26/06/2020 21:35, Jeff King wrote:
> 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

Re: Regarding Git and Branch Naming

[Elijah Newren]

On Fri, Jun 26, 2020 at 1:39 PM Jeff King <peff@peff.net> wrote:
>
> 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

Re: Regarding Git and Branch Naming

[Jeff King]

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

Re: Regarding Git and Branch Naming

[Jeff King]

On 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

Re: Regarding Git and Branch Naming

[Jeff King]

On Fri, Jun 26, 2020 at 02:58:17PM -0700, Elijah Newren wrote:

> 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