From: Tommaso Ercole <Tommaso.Ercole@qlik.com> To: Junio C Hamano <email@example.com>, Jeff King <firstname.lastname@example.org> Cc: Taylor Blau <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: RE: Creation of a branch named that has a directory prefix equal to the name of another branch fail. Date: Mon, 27 Jul 2020 08:21:37 +0000 [thread overview] Message-ID: <DM5PR1801MB20765394FC05BA6830475B7CF0720@DM5PR1801MB2076.namprd18.prod.outlook.com> (raw) In-Reply-To: <firstname.lastname@example.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 <email@example.com> Sent: venerdì 24 luglio 2020 22:44 To: Jeff King <firstname.lastname@example.org> Cc: Taylor Blau <email@example.com>; Tommaso Ercole <Tommaso.Ercole@qlik.com>; firstname.lastname@example.org Subject: Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail. Jeff King <email@example.com> 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 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.
next prev parent reply other threads:[~2020-07-27 8:21 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top [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:00 ` Jeff King 2020-07-24 20:43 ` Junio C Hamano 2020-07-27 8:21 ` Tommaso Ercole [this message] 2020-07-27 9:30 ` Bryan Turner 2020-07-27 8:51 ` Han-Wen Nienhuys 2020-07-24 20:36 ` Junio C Hamano
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=DM5PR1801MB20765394FC05BA6830475B7CF0720@DM5PR1801MB2076.namprd18.prod.outlook.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='RE: Creation of a branch named that has a directory prefix equal to the name of another branch fail.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
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 NNTP newsgroup(s).