git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Regarding Git and Branch Naming

From
Elijah Newren <newren@gmail.com>
Date
Jun 26, 2020, 21:58 UTC
Message-ID
<CABPp-BE7y5YD4A+QTn-2Vu5aS8c_pzQ2096Y7GRqeOOSJKwJHQ@mail.gmail.com>
In-Reply-To
<20200626203539.GA1173768@coredump.intra.peff.net>
On 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
Previous: Jeff KingNext: Jeff King
Message 8 of 9 in “Re: Regarding Git and Branch Naming”
  1. Craig H MaynardJun 26, 2020
  2. Chris TorekJun 26, 2020
  3. Jeff KingJun 26, 2020
  4. Junio C HamanoJun 26, 2020
  5. Jeff KingJun 27, 2020
  6. Philip OakleyJun 26, 2020
  7. Jeff KingJun 27, 2020
  8. Elijah NewrenJun 26, 2020
  9. Jeff KingJun 27, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.