Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
* Re: Regarding Git and Branch Naming
@ 2020-06-26 16:18 Craig H Maynard
  2020-06-26 18:33 ` Chris Torek
  0 siblings, 1 reply; 9+ messages in thread
From: Craig H Maynard @ 2020-06-26 16:18 UTC (permalink / raw)
  To: git

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 16:18 Regarding Git and Branch Naming Craig H Maynard
@ 2020-06-26 18:33 ` Chris Torek
  2020-06-26 20:35   ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: Chris Torek @ 2020-06-26 18:33 UTC (permalink / raw)
  To: Craig H Maynard; +Cc: git

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 18:33 ` Chris Torek
@ 2020-06-26 20:35   ` Jeff King
  2020-06-26 21:07     ` Junio C Hamano
                       ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Jeff King @ 2020-06-26 20:35 UTC (permalink / raw)
  To: Chris Torek; +Cc: Craig H Maynard, git

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 20:35   ` Jeff King
@ 2020-06-26 21:07     ` Junio C Hamano
  2020-06-27  3:05       ` Jeff King
  2020-06-26 21:33     ` Philip Oakley
  2020-06-26 21:58     ` Elijah Newren
  2 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2020-06-26 21:07 UTC (permalink / raw)
  To: Jeff King; +Cc: Chris Torek, Craig H Maynard, git

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.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 20:35   ` Jeff King
  2020-06-26 21:07     ` Junio C Hamano
@ 2020-06-26 21:33     ` Philip Oakley
  2020-06-27  3:11       ` Jeff King
  2020-06-26 21:58     ` Elijah Newren
  2 siblings, 1 reply; 9+ messages in thread
From: Philip Oakley @ 2020-06-26 21:33 UTC (permalink / raw)
  To: Jeff King, Chris Torek; +Cc: Craig H Maynard, git

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 20:35   ` Jeff King
  2020-06-26 21:07     ` Junio C Hamano
  2020-06-26 21:33     ` Philip Oakley
@ 2020-06-26 21:58     ` Elijah Newren
  2020-06-27  3:14       ` Jeff King
  2 siblings, 1 reply; 9+ messages in thread
From: Elijah Newren @ 2020-06-26 21:58 UTC (permalink / raw)
  To: Jeff King; +Cc: Chris Torek, Craig H Maynard, Git Mailing List

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 21:07     ` Junio C Hamano
@ 2020-06-27  3:05       ` Jeff King
  0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2020-06-27  3:05 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Chris Torek, Craig H Maynard, git

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 21:33     ` Philip Oakley
@ 2020-06-27  3:11       ` Jeff King
  0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2020-06-27  3:11 UTC (permalink / raw)
  To: Philip Oakley; +Cc: Chris Torek, Craig H Maynard, git

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Regarding Git and Branch Naming
  2020-06-26 21:58     ` Elijah Newren
@ 2020-06-27  3:14       ` Jeff King
  0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2020-06-27  3:14 UTC (permalink / raw)
  To: Elijah Newren; +Cc: Chris Torek, Craig H Maynard, Git Mailing List

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-26 16:18 Regarding Git and Branch Naming Craig H Maynard
2020-06-26 18:33 ` Chris Torek
2020-06-26 20:35   ` Jeff King
2020-06-26 21:07     ` Junio C Hamano
2020-06-27  3:05       ` Jeff King
2020-06-26 21:33     ` Philip Oakley
2020-06-27  3:11       ` Jeff King
2020-06-26 21:58     ` Elijah Newren
2020-06-27  3:14       ` Jeff King

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git