{"thread":{"id":"53761","subject":"Re: Regarding Git and Branch Naming","startedAt":"2020-06-26T16:23:59Z","lastAt":"2020-06-27T03:14:15Z","messageCount":9,"participants":["Craig H Maynard","Chris Torek","Jeff King","Junio C Hamano","Philip Oakley","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"400707","messageId":"B4814F42-7AF8-4D80-93D4-FAF752C72F21@me.com","threadId":"53761","inReplyTo":null,"subject":"Re: Regarding Git and Branch Naming","fromName":"Craig H Maynard","fromEmail":"chmaynard@me.com","sentAt":"2020-06-26T16:18:03Z","receivedAt":"2020-06-26T16:23:59Z","isPatch":false,"sender":{"key":"chmaynard@me.com","avatar":"https://gravatar.com/avatar/28c48bd37ac090e8adc0ea797e69c0d0965121d535644cdb6eb6ec15dfa7df6d?d=mp&s=160"},"body":"All,\n\nDoes the git init command really need to create a default branch? Perhaps that step could be left to the user.\n\nCraig\n\n--\nCraig H Maynard\nRhode Island, USA\n\n"},{"id":"400712","messageId":"CAPx1GvcZk2o7f8-27xokwxUayWwO+t5qdsMjLrjBymc+WHznmw@mail.gmail.com","threadId":"53761","inReplyTo":"B4814F42-7AF8-4D80-93D4-FAF752C72F21@me.com","subject":"Re: Regarding Git and Branch Naming","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2020-06-26T18:33:53Z","receivedAt":"2020-06-26T18:34:07Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard wrote:\n> Does the git init command really need to create a default branch? Perhaps that step could be left to the user.\n\nThe HEAD pseudo-ref must exist and must contain a valid OID or\nbranch name. (If it does not exist, Git says that the directory\nis not a repository. Perhaps this test could be weakened, but\nthat's definitely a fairly big change.)\n\nIn a new, empty repository there are no valid OIDs, so HEAD must\ncontain a branch name. The branch itself need not exist, but\nwhatever name is in HEAD is the branch that will be created\nwhen the user makes the first commit.\n\nChris\n"},{"id":"400715","messageId":"20200626203539.GA1173768@coredump.intra.peff.net","threadId":"53761","inReplyTo":"CAPx1GvcZk2o7f8-27xokwxUayWwO+t5qdsMjLrjBymc+WHznmw@mail.gmail.com","subject":"Re: Regarding Git and Branch Naming","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-26T20:35:39Z","receivedAt":"2020-06-26T20:35:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 26, 2020 at 11:33:53AM -0700, Chris Torek wrote:\n\n> On Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard wrote:\n> > Does the git init command really need to create a default branch? Perhaps that step could be left to the user.\n> \n> The HEAD pseudo-ref must exist and must contain a valid OID or\n> branch name. (If it does not exist, Git says that the directory\n> is not a repository. Perhaps this test could be weakened, but\n> that's definitely a fairly big change.)\n> \n> In a new, empty repository there are no valid OIDs, so HEAD must\n> contain a branch name. The branch itself need not exist, but\n> whatever name is in HEAD is the branch that will be created\n> when the user makes the first commit.\n\nWe definitely _could_ extend HEAD to allow a \"not pointing at anything\"\nstate. Presumably for reading that would behave like the \"pointing at a\nbranch that doesn't exist yet\" case. But I think the experience it\ncreates for writing is not very good. I.e., I think the best we could do\nis something like:\n\n $ git init\n $ git add some-files\n $ git commit -m whatever\n fatal: HEAD does not point to any branch\n hint: use \"git checkout -b \" to make commits on \n\nPerhaps that's not _too_ bad, but it feels a bit unfriendly (and\ndefinitely more likely to cause backwards compatibility issues than\npicking _some_ default name). There would also be a lot of corner cases\nto cover and debug (e.g., \"git checkout foo\" moving away from the \"no\nbranch\" state should make the usual complaints if we'd have to overwrite\nor modify index and untracked files).\n\n-Peff\n"},{"id":"400716","messageId":"xmqq7dvth6xy.fsf@gitster.c.googlers.com","threadId":"53761","inReplyTo":"20200626203539.GA1173768@coredump.intra.peff.net","subject":"Re: Regarding Git and Branch Naming","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-26T21:07:37Z","receivedAt":"2020-06-26T21:07:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> We definitely _could_ extend HEAD to allow a \"not pointing at anything\"\n> state. Presumably for reading that would behave like the \"pointing at a\n> branch that doesn't exist yet\" case. But I think the experience it\n> creates for writing is not very good. I.e., I think the best we could do\n> is something like:\n>\n> $ git init\n> $ git add some-files\n> $ git commit -m whatever\n> fatal: HEAD does not point to any branch\n> hint: use \"git checkout -b \" to make commits on \n\n... or you could stay forever on detached HEAD state.\n\nVery briefly in early days of Git, the envisioned use case (which\nquickly was retracted) was to use one repository per one line of\ndevelopment (so you'd pull among the repositories you have, and each\nrepository does not even need to have \"the default\" branch---there\nwas no need for any branch). Staying forever on detached HEAD is\npretty much in line with that.\n\n> Perhaps that's not _too_ bad, but it feels a bit unfriendly (and\n> definitely more likely to cause backwards compatibility issues than\n> picking _some_ default name). There would also be a lot of corner cases\n> to cover and debug (e.g., \"git checkout foo\" moving away from the \"no\n> branch\" state should make the usual complaints if we'd have to overwrite\n> or modify index and untracked files).\n\nI do not see much point in adding such a new set-up, only to risk\nintroducing unexpected and unnecessary bugs. Such extra engineering\nresource is better spent elsewhere, I would say.\n\n\n\n"},{"id":"400720","messageId":"6b9d76e4-68dd-8e57-f96a-318579dea6f3@iee.email","threadId":"53761","inReplyTo":"20200626203539.GA1173768@coredump.intra.peff.net","subject":"Re: Regarding Git and Branch Naming","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-06-26T21:33:14Z","receivedAt":"2020-06-26T21:33:19Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 26/06/2020 21:35, Jeff King wrote:\n> On Fri, Jun 26, 2020 at 11:33:53AM -0700, Chris Torek wrote:\n>\n>> On Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard wrote:\n>>> Does the git init command really need to create a default branch? Perhaps that step could be left to the user.\n>> The HEAD pseudo-ref must exist and must contain a valid OID or\n>> branch name. (If it does not exist, Git says that the directory\n>> is not a repository. Perhaps this test could be weakened, but\n>> that's definitely a fairly big change.)\n>>\n>> In a new, empty repository there are no valid OIDs, so HEAD must\n>> contain a branch name. The branch itself need not exist, but\n>> whatever name is in HEAD is the branch that will be created\n>> when the user makes the first commit.\n> We definitely _could_ extend HEAD to allow a \"not pointing at anything\"\n> state. Presumably for reading that would behave like the \"pointing at a\n> branch that doesn't exist yet\" case. But I think the experience it\n> creates for writing is not very good. I.e., I think the best we could do\n> is something like:\n>\n> $ git init\n> $ git add some-files\n> $ git commit -m whatever\n> fatal: HEAD does not point to any branch\n> hint: use \"git checkout -b \" to make commits on \n>\n> Perhaps that's not _too_ bad, but it feels a bit unfriendly (and\n> definitely more likely to cause backwards compatibility issues than\n> picking _some_ default name). There would also be a lot of corner cases\n> to cover and debug (e.g., \"git checkout foo\" moving away from the \"no\n> branch\" state should make the usual complaints if we'd have to overwrite\n> or modify index and untracked files).\n>\n>\nA wild bikeshed question: Is HEAD itself protected as a branch name e.g.\nthat HEAD could contain `ref: HEAD` or `ref: refs/heads/HEAD`? (or maybe\nthe null  oid\n\nIt sort of feels that we may already have some sort of protection for\nthe first self reference - i.e. exists, but not defined (self-reference).\n\nPhilip\n"},{"id":"400724","messageId":"CABPp-BE7y5YD4A+QTn-2Vu5aS8c_pzQ2096Y7GRqeOOSJKwJHQ@mail.gmail.com","threadId":"53761","inReplyTo":"20200626203539.GA1173768@coredump.intra.peff.net","subject":"Re: Regarding Git and Branch Naming","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-06-26T21:58:17Z","receivedAt":"2020-06-26T21:58:30Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jun 26, 2020 at 1:39 PM Jeff King wrote:\n>\n> On Fri, Jun 26, 2020 at 11:33:53AM -0700, Chris Torek wrote:\n>\n> > On Fri, Jun 26, 2020 at 10:19 AM Craig H Maynard wrote:\n> > > Does the git init command really need to create a default branch? Perhaps that step could be left to the user.\n> >\n> > The HEAD pseudo-ref must exist and must contain a valid OID or\n> > branch name. (If it does not exist, Git says that the directory\n> > is not a repository. Perhaps this test could be weakened, but\n> > that's definitely a fairly big change.)\n> >\n> > In a new, empty repository there are no valid OIDs, so HEAD must\n> > contain a branch name. The branch itself need not exist, but\n> > whatever name is in HEAD is the branch that will be created\n> > when the user makes the first commit.\n>\n> We definitely _could_ extend HEAD to allow a \"not pointing at anything\"\n> state. Presumably for reading that would behave like the \"pointing at a\n> branch that doesn't exist yet\" case. But I think the experience it\n> creates for writing is not very good. I.e., I think the best we could do\n> is something like:\n>\n> $ git init\n> $ git add some-files\n> $ git commit -m whatever\n> fatal: HEAD does not point to any branch\n> hint: use \"git checkout -b \" to make commits on \n>\n> Perhaps that's not _too_ bad, but it feels a bit unfriendly (and\n> definitely more likely to cause backwards compatibility issues than\n> picking _some_ default name). There would also be a lot of corner cases\n> to cover and debug (e.g., \"git checkout foo\" moving away from the \"no\n> branch\" state should make the usual complaints if we'd have to overwrite\n> or modify index and untracked files).\n>\n> -Peff\n\nThe error doesn't need to come that late; it could come at the \"init\"\nstep when no branch name is specified. If that's desirable, a\nnecessary first step towards that would be making a plain \"git init\"\nthrow a warning that we are creating a repo with a default branch name\nof since the user didn't specify one.\n\nOf course, we could decide to only take that first step and never\nescalate it to an error. It'd still leave us with some default name,\nbut would de-emphasize it some.\n\nNot sure if I'm in favor of either of these ideas or not, but just\nthought I'd point out alternate possibilities towards\nremoving/de-emphasizing the default initial branch name.\n\nElijah\n"},{"id":"400725","messageId":"20200627030532.GA1187031@coredump.intra.peff.net","threadId":"53761","inReplyTo":"xmqq7dvth6xy.fsf@gitster.c.googlers.com","subject":"Re: Regarding Git and Branch Naming","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-27T03:05:32Z","receivedAt":"2020-06-27T03:05:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 26, 2020 at 02:07:37PM -0700, Junio C Hamano wrote:\n\n> > $ git init\n> > $ git add some-files\n> > $ git commit -m whatever\n> > fatal: HEAD does not point to any branch\n> > hint: use \"git checkout -b \" to make commits on \n> \n> ... or you could stay forever on detached HEAD state.\n> \n> Very briefly in early days of Git, the envisioned use case (which\n> quickly was retracted) was to use one repository per one line of\n> development (so you'd pull among the repositories you have, and each\n> repository does not even need to have \"the default\" branch---there\n> was no need for any branch). Staying forever on detached HEAD is\n> pretty much in line with that.\n\nGiven the difficulties many users seem to have with understanding\ndetached HEADs, I think that might be even more unfriendly. :)\n\n> > Perhaps that's not _too_ bad, but it feels a bit unfriendly (and\n> > definitely more likely to cause backwards compatibility issues than\n> > picking _some_ default name). There would also be a lot of corner cases\n> > to cover and debug (e.g., \"git checkout foo\" moving away from the \"no\n> > branch\" state should make the usual complaints if we'd have to overwrite\n> > or modify index and untracked files).\n> \n> I do not see much point in adding such a new set-up, only to risk\n> introducing unexpected and unnecessary bugs. Such extra engineering\n> resource is better spent elsewhere, I would say.\n\nYeah, agreed.\n\n-Peff\n"},{"id":"400726","messageId":"20200627031111.GB1187031@coredump.intra.peff.net","threadId":"53761","inReplyTo":"6b9d76e4-68dd-8e57-f96a-318579dea6f3@iee.email","subject":"Re: Regarding Git and Branch Naming","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-27T03:11:11Z","receivedAt":"2020-06-27T03:11:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 26, 2020 at 10:33:14PM +0100, Philip Oakley wrote:\n\n> A wild bikeshed question: Is HEAD itself protected as a branch name e.g.\n> that HEAD could contain `ref: HEAD` or `ref: refs/heads/HEAD`? (or maybe\n> the null  oid\n\nThe first is not legal; we insist that symrefs start with \"refs/\". The\nsecond one _is_ legal, but isn't any kind of loop. The HEAD symref is\n.git/HEAD, which is distinct from a ref of the same name inside\nrefs/heads/.\n\nIt's confusing, of course, because the lookup rules make it hard to\nrefer to refs/heads/HEAD. For that reason we do disallow it from the\nbranch-creation porcelains like git-branch and git-checkout.\n\n-Peff\n"},{"id":"400727","messageId":"20200627031412.GC1187031@coredump.intra.peff.net","threadId":"53761","inReplyTo":"CABPp-BE7y5YD4A+QTn-2Vu5aS8c_pzQ2096Y7GRqeOOSJKwJHQ@mail.gmail.com","subject":"Re: Regarding Git and Branch Naming","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-27T03:14:12Z","receivedAt":"2020-06-27T03:14:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 26, 2020 at 02:58:17PM -0700, Elijah Newren wrote:\n\n> The error doesn't need to come that late; it could come at the \"init\"\n> step when no branch name is specified. If that's desirable, a\n> necessary first step towards that would be making a plain \"git init\"\n> throw a warning that we are creating a repo with a default branch name\n> of since the user didn't specify one.\n> \n> Of course, we could decide to only take that first step and never\n> escalate it to an error. It'd still leave us with some default name,\n> but would de-emphasize it some.\n> \n> Not sure if I'm in favor of either of these ideas or not, but just\n> thought I'd point out alternate possibilities towards\n> removing/de-emphasizing the default initial branch name.\n\nYeah, I agree those are all possible options. My issue is that not\npicking a default means the user is forced to do so before continuing,\nwhich seems fundamentally unfriendly to me. It's putting more friction\nbetween the user and their goal.\n\nThe warning version doesn't force that choice, but then I don't think\nthat's it really accomplished that much. We've still got to have a\ndefault, and now we have an annoying warning on top. :)\n\n-Peff\n"}]}