From: Jeff King <email@example.com> To: Taylor Blau <firstname.lastname@example.org> Cc: Tommaso Ercole <Tommaso.Ercole@qlik.com>, "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. Date: Fri, 24 Jul 2020 16:00:42 -0400 [thread overview] Message-ID: <20200724200042.GC4013174@coredump.intra.peff.net> (raw) In-Reply-To: <20200724160045.GA10590@syl.lan> 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 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  I didn't actually check what the current reftable patches do, but that's my recollection from discussions long ago.
next prev parent reply other threads:[~2020-07-24 20:00 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 [this message] 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
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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200724200042.GC4013174@coredump.intra.peff.net \ --email@example.com \ --cc=Tommaso.Ercole@qlik.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.' \ /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
Code repositories for project(s) associated with this 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).