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

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

[Tommaso Ercole]

[-- 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]

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

[Taylor Blau]

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

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

[Jeff King]

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.

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

[Junio C Hamano]

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.

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

[Junio C Hamano]

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.

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

[Tommaso Ercole]

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.

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

[Han-Wen Nienhuys]

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

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

[Bryan Turner]

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.