* Creation of a branch named that has a directory prefix equal to the name of another branch fail. [not found] <DM5PR1801MB2076F807C0B9F29A152DBEB7F0760@DM5PR1801MB2076.namprd18.prod.outlook.com> @ 2020-07-24 10:26 ` Tommaso Ercole 2020-07-24 16:00 ` Taylor Blau 2020-07-24 20:36 ` Junio C Hamano 0 siblings, 2 replies; 8+ messages in thread From: Tommaso Ercole @ 2020-07-24 10:26 UTC (permalink / raw) To: git@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 918 bytes --] 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. I.E. 'a/b/c' when 'a/b' just exists. Best regards, Tommaso Ercole Head Programmer Content Delivery Mobile: +39 328 7182833 Email: mailto:tommaso.ercole@qlik.com Skype: live:tommaso.ercole Qlik via Brescia 31 36040 Torri di Quartesolo - Vicenza - Italy http://www.qlik.com/ http://qlik.com/ The 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. [-- Attachment #2: git-bugreport-2020-07-23-1754.txt --] [-- Type: text/plain, Size: 739 bytes --] Creating a branch a/b/c when a/b exists fails complaining that a ref 'a/b' just exists. This is probably due to the fact that when creating a/b a directory 'a' is created inside 'refs/heads' and a file 'b' is created under the a directory, avoiding the subsequent possibility to create a folder 'b' in the same directory that is needed to create the ref for 'a/b/c' The solution seems to append to the file an extension to disambiguate the file from the folder. [System Info] git version: git version 2.27.0.windows.1 cpu: x86_64 built from commit: 907ab1011dce9112700498e034b974ba60f8b407 sizeof-long: 4 sizeof-size_t: 8 uname: Windows 10.0 18363 compiler info: gnuc: 10.1 libc info: no libc information available [Enabled Hooks] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. 2020-07-24 10:26 ` Creation of a branch named that has a directory prefix equal to the name of another branch fail Tommaso Ercole @ 2020-07-24 16:00 ` Taylor Blau 2020-07-24 20:00 ` Jeff King 2020-07-24 20:36 ` Junio C Hamano 1 sibling, 1 reply; 8+ messages in thread From: Taylor Blau @ 2020-07-24 16:00 UTC (permalink / raw) To: Tommaso Ercole; +Cc: git@vger.kernel.org Hi Tommaso, On Fri, Jul 24, 2020 at 10:26:14AM +0000, Tommaso Ercole wrote: > 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. > > I.E. 'a/b/c' when 'a/b' just exists. This is a known limitation of loose references, since each reference is stored in a file in $GITDIR/refs. Reftable support within Git will lift this limitation. In the meantime, if your references aren't updated you can store them as packed refs which don't have this limitation, but note that they will be expanded loose if you touch them again (i.e., this is a good solution for tags, but not development branches). Hope that this helps. > Best regards, > Tommaso Ercole > Head Programmer > Content Delivery Thanks, Taylor ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. 2020-07-24 16:00 ` Taylor Blau @ 2020-07-24 20:00 ` Jeff King 2020-07-24 20:43 ` Junio C Hamano 2020-07-27 8:51 ` Han-Wen Nienhuys 0 siblings, 2 replies; 8+ messages in thread From: Jeff King @ 2020-07-24 20:00 UTC (permalink / raw) To: Taylor Blau; +Cc: Tommaso Ercole, git@vger.kernel.org On Fri, Jul 24, 2020 at 12:00:45PM -0400, Taylor Blau wrote: > On Fri, Jul 24, 2020 at 10:26:14AM +0000, Tommaso Ercole wrote: > > 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. > > > > I.E. 'a/b/c' when 'a/b' just exists. > > This is a known limitation of loose references, since each reference is > stored in a file in $GITDIR/refs. > > Reftable support within Git will lift this limitation. In the meantime, > if your references aren't updated you can store them as packed refs > which don't have this limitation, but note that they will be expanded > loose if you touch them again (i.e., this is a good solution for tags, > but not development branches). Note that even though packed-refs does not have this limitation, we still enforce it in order to avoid headaches when moving between loose and packed refs. Likewise, we'll probably[1] continue to enforce it with reftables, at least for a while, to make things less confusing when pushing and pulling between repositories with different storage. If reftables become the widespread default, then I imagine we'd consider loosening it then (or alternatively, adding a config option for people who want the flexibility and don't mind the interoperability cost). -Peff [1] I didn't actually check what the current reftable patches do, but that's my recollection from discussions long ago. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. 2020-07-24 20:00 ` Jeff King @ 2020-07-24 20:43 ` Junio C Hamano 2020-07-27 8:21 ` Tommaso Ercole 2020-07-27 8:51 ` Han-Wen Nienhuys 1 sibling, 1 reply; 8+ messages in thread From: Junio C Hamano @ 2020-07-24 20:43 UTC (permalink / raw) To: Jeff King; +Cc: Taylor Blau, Tommaso Ercole, git@vger.kernel.org Jeff King <peff@peff.net> writes: > Note that even though packed-refs does not have this limitation, we > still enforce it in order to avoid headaches when moving between loose > and packed refs. > > Likewise, we'll probably[1] continue to enforce it with reftables, at > least for a while, to make things less confusing when pushing and > pulling between repositories with different storage. Yup, that coincides with my understanding. 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. 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Creation of a branch named that has a directory prefix equal to the name of another branch fail. 2020-07-24 20:43 ` Junio C Hamano @ 2020-07-27 8:21 ` Tommaso Ercole 2020-07-27 9:30 ` Bryan Turner 0 siblings, 1 reply; 8+ messages in thread From: Tommaso Ercole @ 2020-07-27 8:21 UTC (permalink / raw) To: Junio C Hamano, Jeff King; +Cc: Taylor Blau, git@vger.kernel.org Hi all and thanks for the answers. By my understanding it seems that you are aware of all the problems and you have just in place a solution for the future. I will just wait for it. Thank you really much for your effort, best regards, Tommaso Ercole 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... -----Original Message----- From: Junio C Hamano <gitster@pobox.com> Sent: venerdì 24 luglio 2020 22:44 To: Jeff King <peff@peff.net> Cc: Taylor Blau <me@ttaylorr.com>; Tommaso Ercole <Tommaso.Ercole@qlik.com>; git@vger.kernel.org Subject: Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. Jeff King <peff@peff.net> writes: > Note that even though packed-refs does not have this limitation, we > still enforce it in order to avoid headaches when moving between loose > and packed refs. > > Likewise, we'll probably[1] continue to enforce it with reftables, at > least for a while, to make things less confusing when pushing and > pulling between repositories with different storage. Yup, that coincides with my understanding. 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. 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. 2020-07-27 8:21 ` Tommaso Ercole @ 2020-07-27 9:30 ` Bryan Turner 0 siblings, 0 replies; 8+ messages in thread From: Bryan Turner @ 2020-07-27 9:30 UTC (permalink / raw) To: Tommaso Ercole Cc: Junio C Hamano, Jeff King, Taylor Blau, git@vger.kernel.org On Mon, Jul 27, 2020 at 1:21 AM Tommaso Ercole <Tommaso.Ercole@qlik.com> wrote: > > Hi all and thanks for the answers. > > By my understanding it seems that you are aware of all the problems and you have just in place a solution for the future. > > I will just wait for it. > > Thank you really much for your effort, best regards, > Tommaso Ercole > > 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... It's a public list, which anyone can register for, and it also has multiple archives, like: https://lore.kernel.org/git/DM5PR1801MB20762477763E6298C7FE6315F0770@DM5PR1801MB2076.namprd18.prod.outlook.com/ I don't think there's any way to scrub the data now. Even if it was removed from lore.kernel.org as a one-off, the original email was delivered to the entire list. > > > -----Original Message----- > From: Junio C Hamano <gitster@pobox.com> > Sent: venerdì 24 luglio 2020 22:44 > To: Jeff King <peff@peff.net> > Cc: Taylor Blau <me@ttaylorr.com>; Tommaso Ercole <Tommaso.Ercole@qlik.com>; git@vger.kernel.org > Subject: Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. > > Jeff King <peff@peff.net> writes: > > > Note that even though packed-refs does not have this limitation, we > > still enforce it in order to avoid headaches when moving between loose > > and packed refs. > > > > Likewise, we'll probably[1] continue to enforce it with reftables, at > > least for a while, to make things less confusing when pushing and > > pulling between repositories with different storage. > > Yup, that coincides with my understanding. > > 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. > > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. 2020-07-24 20:00 ` Jeff King 2020-07-24 20:43 ` Junio C Hamano @ 2020-07-27 8:51 ` Han-Wen Nienhuys 1 sibling, 0 replies; 8+ messages in thread From: Han-Wen Nienhuys @ 2020-07-27 8:51 UTC (permalink / raw) To: Jeff King; +Cc: Taylor Blau, Tommaso Ercole, git@vger.kernel.org On Fri, Jul 24, 2020 at 10:00 PM Jeff King <peff@peff.net> wrote: > [1] I didn't actually check what the current reftable patches do, but > that's my recollection from discussions long ago. struct reftable_write_options has a skip_name_check setting. If set, it doesn't check for directory/file conflicts. If unset, any attempt to create such conflicts will API_ERROR from the transaction commit function. -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. 2020-07-24 10:26 ` Creation of a branch named that has a directory prefix equal to the name of another branch fail Tommaso Ercole 2020-07-24 16:00 ` Taylor Blau @ 2020-07-24 20:36 ` Junio C Hamano 1 sibling, 0 replies; 8+ messages in thread From: Junio C Hamano @ 2020-07-24 20:36 UTC (permalink / raw) To: Tommaso Ercole; +Cc: git@vger.kernel.org Tommaso Ercole <Tommaso.Ercole@qlik.com> writes: > 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. > > I.E. 'a/b/c' when 'a/b' just exists. Yup, that is one of the natural consequences of the design to organize refs in a directory like hierarchies. There are various ref backends (e.g. packed-refs that already exists, and reftable) that could potentially store both D and D/F at the same time, but it is very likely that the higher layer that calls into these ref backends will keep the behaviour as a policy, to ensure that those on older versions of Git can smoothly interoperate with newer versions of Git. Thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-07-27 9:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <DM5PR1801MB2076F807C0B9F29A152DBEB7F0760@DM5PR1801MB2076.namprd18.prod.outlook.com> 2020-07-24 10:26 ` Creation of a branch named that has a directory prefix equal to the name of another branch fail Tommaso Ercole 2020-07-24 16:00 ` Taylor Blau 2020-07-24 20:00 ` Jeff King 2020-07-24 20:43 ` Junio C Hamano 2020-07-27 8:21 ` Tommaso Ercole 2020-07-27 9:30 ` Bryan Turner 2020-07-27 8:51 ` Han-Wen Nienhuys 2020-07-24 20:36 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).