Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.

From: Jeff King <peff@peff.net>
Date: Jul 24, 2020, 20:00 UTC
Message-ID: <20200724200042.GC4013174@coredump.intra.peff.net>
In-Reply-To: <20200724160045.GA10590@syl.lan>

On Fri, Jul 24, 2020 at 12:00:45PM -0400, Taylor Blau wrote:

Show 13 quoted lines

> 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.