{"thread":{"id":"53917","subject":"Creation of a branch named that has a directory prefix equal to the name of another branch fail.","startedAt":"2020-07-24T10:26:18Z","lastAt":"2020-07-27T09:30:29Z","messageCount":8,"participants":["Tommaso Ercole","Taylor Blau","Jeff King","Junio C Hamano","Han-Wen Nienhuys","Bryan Turner"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"401990","messageId":"DM5PR1801MB20762477763E6298C7FE6315F0770@DM5PR1801MB2076.namprd18.prod.outlook.com","threadId":"53917","inReplyTo":"DM5PR1801MB2076F807C0B9F29A152DBEB7F0760@DM5PR1801MB2076.namprd18.prod.outlook.com","subject":"Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Tommaso Ercole","fromEmail":"tommaso.ercole@qlik.com","sentAt":"2020-07-24T10:26:14Z","receivedAt":"2020-07-24T10:26:18Z","isPatch":false,"sender":{"key":"tommaso.ercole@qlik.com","avatar":null},"body":"As per compiled bug report, creation of a branch that has a prefix that map to a folder, when that prefix is just an existing branch in the repo fails.\n\nI.E. 'a/b/c' when 'a/b' just exists.\n\nBest regards,\nTommaso Ercole \nHead Programmer\nContent Delivery\n\nMobile: +39 328 7182833\nEmail:  mailto:tommaso.ercole@qlik.com \nSkype:  live:tommaso.ercole\n\nQlik\nvia Brescia 31\n36040 Torri di Quartesolo - Vicenza - Italy \n\nhttp://www.qlik.com/\nhttp://qlik.com/\n\nThe information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.\n\n\n\nCreating a branch a/b/c when a/b exists fails complaining that a ref 'a/b' just exists.\n\nThis is probably due to the fact that when creating a/b a directory 'a' is created inside \n'refs/heads' and a file 'b' is created under the a directory, avoiding the subsequent possibility \nto create a folder 'b' in the same directory that is needed to create the ref for 'a/b/c'\n\nThe solution seems to append to the file an extension to disambiguate the file from the folder.\n\n[System Info]\ngit version:\ngit version 2.27.0.windows.1\ncpu: x86_64\nbuilt from commit: 907ab1011dce9112700498e034b974ba60f8b407\nsizeof-long: 4\nsizeof-size_t: 8\nuname: Windows 10.0 18363 \ncompiler info: gnuc: 10.1\nlibc info: no libc information available\n\n\n[Enabled Hooks]\n"},{"id":"402003","messageId":"20200724160045.GA10590@syl.lan","threadId":"53917","inReplyTo":"DM5PR1801MB20762477763E6298C7FE6315F0770@DM5PR1801MB2076.namprd18.prod.outlook.com","subject":"Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-07-24T16:00:45Z","receivedAt":"2020-07-24T16:00:50Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hi Tommaso,\n\nOn Fri, Jul 24, 2020 at 10:26:14AM +0000, Tommaso Ercole wrote:\n> As per compiled bug report, creation of a branch that has a prefix that map to a folder, when that prefix is just an existing branch in the repo fails.\n>\n> I.E. 'a/b/c' when 'a/b' just exists.\n\nThis is a known limitation of loose references, since each reference is\nstored in a file in $GITDIR/refs.\n\nReftable support within Git will lift this limitation. In the meantime,\nif your references aren't updated you can store them as packed refs\nwhich don't have this limitation, but note that they will be expanded\nloose if you touch them again (i.e., this is a good solution for tags,\nbut not development branches).\n\nHope that this helps.\n\n> Best regards,\n> Tommaso Ercole\n> Head Programmer\n> Content Delivery\n\nThanks,\nTaylor\n"},{"id":"402019","messageId":"20200724200042.GC4013174@coredump.intra.peff.net","threadId":"53917","inReplyTo":"20200724160045.GA10590@syl.lan","subject":"Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-07-24T20:00:42Z","receivedAt":"2020-07-24T20:00:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 24, 2020 at 12:00:45PM -0400, Taylor Blau wrote:\n\n> On Fri, Jul 24, 2020 at 10:26:14AM +0000, Tommaso Ercole wrote:\n> > As per compiled bug report, creation of a branch that has a prefix that map to a folder, when that prefix is just an existing branch in the repo fails.\n> >\n> > I.E. 'a/b/c' when 'a/b' just exists.\n> \n> This is a known limitation of loose references, since each reference is\n> stored in a file in $GITDIR/refs.\n> \n> Reftable support within Git will lift this limitation. In the meantime,\n> if your references aren't updated you can store them as packed refs\n> which don't have this limitation, but note that they will be expanded\n> loose if you touch them again (i.e., this is a good solution for tags,\n> but not development branches).\n\nNote that even though packed-refs does not have this limitation, we\nstill enforce it in order to avoid headaches when moving between loose\nand packed refs.\n\nLikewise, we'll probably[1] continue to enforce it with reftables, at\nleast for a while, to make things less confusing when pushing and\npulling between repositories with different storage. If reftables become\nthe widespread default, then I imagine we'd consider loosening it then\n(or alternatively, adding a config option for people who want the\nflexibility and don't mind the interoperability cost).\n\n-Peff\n\n[1] I didn't actually check what the current reftable patches do, but\n that's my recollection from discussions long ago.\n"},{"id":"402023","messageId":"xmqqzh7ok5vu.fsf@gitster.c.googlers.com","threadId":"53917","inReplyTo":"DM5PR1801MB20762477763E6298C7FE6315F0770@DM5PR1801MB2076.namprd18.prod.outlook.com","subject":"Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-07-24T20:36:05Z","receivedAt":"2020-07-24T20:36:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tommaso Ercole writes:\n\n> As per compiled bug report, creation of a branch that has a prefix that map to a folder, when that prefix is just an existing branch in the repo fails.\n>\n> I.E. 'a/b/c' when 'a/b' just exists.\n\nYup, that is one of the natural consequences of the design to\norganize refs in a directory like hierarchies. There are various\nref backends (e.g. packed-refs that already exists, and reftable)\nthat could potentially store both D and D/F at the same time, but\nit is very likely that the higher layer that calls into these ref\nbackends will keep the behaviour as a policy, to ensure that those\non older versions of Git can smoothly interoperate with newer\nversions of Git.\n\nThanks.\n"},{"id":"402024","messageId":"xmqqv9ick5j4.fsf@gitster.c.googlers.com","threadId":"53917","inReplyTo":"20200724200042.GC4013174@coredump.intra.peff.net","subject":"Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-07-24T20:43:43Z","receivedAt":"2020-07-24T20:43:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Note that even though packed-refs does not have this limitation, we\n> still enforce it in order to avoid headaches when moving between loose\n> and packed refs.\n>\n> Likewise, we'll probably[1] continue to enforce it with reftables, at\n> least for a while, to make things less confusing when pushing and\n> pulling between repositories with different storage.\n\nYup, that coincides with my understanding.\n\nThe files backend could also learn encoding/decoding refnames and\nthat could be used to transition, if/when we decide to discard the\n\"refs are organized in a directory-tree like fashion\" design we have\nbeen using, to a new world order where a branch M and branches M/A,\nM/B, and M/C can co-exist. Encoding/decoding refname to map to the\nfilename would also help those on case insensitive filesystems.\n\nThanks to the recent preparation work for reftable, we are ensuring\nthat we do not leave direct accesses to $GIT_DIR/refs/* in our\ncodebase outside the files backend implementation, such a transition\nhopefully is getting much easier to do than before.\n"},{"id":"402126","messageId":"DM5PR1801MB20765394FC05BA6830475B7CF0720@DM5PR1801MB2076.namprd18.prod.outlook.com","threadId":"53917","inReplyTo":"xmqqv9ick5j4.fsf@gitster.c.googlers.com","subject":"RE: Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Tommaso Ercole","fromEmail":"tommaso.ercole@qlik.com","sentAt":"2020-07-27T08:21:37Z","receivedAt":"2020-07-27T08:21:42Z","isPatch":false,"sender":{"key":"tommaso.ercole@qlik.com","avatar":null},"body":"Hi all and thanks for the answers. \n\nBy my understanding it seems that you are aware of all the problems and you have just in place a solution for the future.\n\nI will just wait for it.\n\nThank you really much for your effort, best regards,\nTommaso Ercole \n\nP.S. btw this chat is it private between us or published somewhere, I just thought about it now, when I saw my phone number on my signature...\n\n\n-----Original Message-----\nFrom: Junio C Hamano \nSent: venerdì 24 luglio 2020 22:44\nTo: Jeff King \nCc: Taylor Blau ; Tommaso Ercole ; git@vger.kernel.org\nSubject: Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.\n\nJeff King writes:\n\n> Note that even though packed-refs does not have this limitation, we \n> still enforce it in order to avoid headaches when moving between loose \n> and packed refs.\n>\n> Likewise, we'll probably[1] continue to enforce it with reftables, at \n> least for a while, to make things less confusing when pushing and \n> pulling between repositories with different storage.\n\nYup, that coincides with my understanding.\n\nThe files backend could also learn encoding/decoding refnames and that could be used to transition, if/when we decide to discard the \"refs are organized in a directory-tree like fashion\" design we have been using, to a new world order where a branch M and branches M/A, M/B, and M/C can co-exist. Encoding/decoding refname to map to the filename would also help those on case insensitive filesystems.\n\nThanks to the recent preparation work for reftable, we are ensuring that we do not leave direct accesses to $GIT_DIR/refs/* in our codebase outside the files backend implementation, such a transition hopefully is getting much easier to do than before.\n"},{"id":"402128","messageId":"CAFQ2z_O7D_9ToECfMhh3mbRproktM+gTR_-byajatH3+7-ziLg@mail.gmail.com","threadId":"53917","inReplyTo":"20200724200042.GC4013174@coredump.intra.peff.net","subject":"Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2020-07-27T08:51:28Z","receivedAt":"2020-07-27T08:51:44Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Fri, Jul 24, 2020 at 10:00 PM Jeff King wrote:\n> [1] I didn't actually check what the current reftable patches do, but\n> that's my recollection from discussions long ago.\n\nstruct reftable_write_options has a skip_name_check setting. If set,\nit doesn't check for directory/file conflicts. If unset, any attempt\nto create such conflicts will API_ERROR from the transaction commit\nfunction.\n\n-- \nHan-Wen Nienhuys - Google Munich\nI work 80%. Don't expect answers from me on Fridays.\n--\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\nRegistergericht und -nummer: Hamburg, HRB 86891\nSitz der Gesellschaft: Hamburg\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"},{"id":"402129","messageId":"CAGyf7-E6uyBnDZ7Uaz9awbUzgfPCabYeRNcYbw+yaHXDiLPdxw@mail.gmail.com","threadId":"53917","inReplyTo":"DM5PR1801MB20765394FC05BA6830475B7CF0720@DM5PR1801MB2076.namprd18.prod.outlook.com","subject":"Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2020-07-27T09:30:15Z","receivedAt":"2020-07-27T09:30:29Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Mon, Jul 27, 2020 at 1:21 AM Tommaso Ercole wrote:\n>\n> Hi all and thanks for the answers.\n>\n> By my understanding it seems that you are aware of all the problems and you have just in place a solution for the future.\n>\n> I will just wait for it.\n>\n> Thank you really much for your effort, best regards,\n> Tommaso Ercole\n>\n> P.S. btw this chat is it private between us or published somewhere, I just thought about it now, when I saw my phone number on my signature...\n\nIt's a public list, which anyone can register for, and it also has\nmultiple archives, like:\nhttps://lore.kernel.org/git/DM5PR1801MB20762477763E6298C7FE6315F0770@DM5PR1801MB2076.namprd18.prod.outlook.com/\n\nI don't think there's any way to scrub the data now. Even if it was\nremoved from lore.kernel.org as a one-off, the original email was\ndelivered to the entire list.\n\n>\n>\n> -----Original Message-----\n> From: Junio C Hamano \n> Sent: venerdì 24 luglio 2020 22:44\n> To: Jeff King \n> Cc: Taylor Blau ; Tommaso Ercole ; git@vger.kernel.org\n> Subject: Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.\n>\n> Jeff King writes:\n>\n> > Note that even though packed-refs does not have this limitation, we\n> > still enforce it in order to avoid headaches when moving between loose\n> > and packed refs.\n> >\n> > Likewise, we'll probably[1] continue to enforce it with reftables, at\n> > least for a while, to make things less confusing when pushing and\n> > pulling between repositories with different storage.\n>\n> Yup, that coincides with my understanding.\n>\n> The files backend could also learn encoding/decoding refnames and that could be used to transition, if/when we decide to discard the \"refs are organized in a directory-tree like fashion\" design we have been using, to a new world order where a branch M and branches M/A, M/B, and M/C can co-exist. Encoding/decoding refname to map to the filename would also help those on case insensitive filesystems.\n>\n> Thanks to the recent preparation work for reftable, we are ensuring that we do not leave direct accesses to $GIT_DIR/refs/* in our codebase outside the files backend implementation, such a transition hopefully is getting much easier to do than before.\n"}]}