Bug: git branch -D can be used to delete branch which is currently checked out

Bug: git branch -D can be used to delete branch which is currently checked out

[Marcus Kida]

Testes on: 

Mac OS X 10.11.3 (El Capitan) using Git 2.6.4

Issue:

git branch -D can be used to delete branch which is currently checked out

Steps to reproduce:

inside a git repository:

$ git checkout -b feature/myAwesomeFeature

-> you end up in feature/myAwesomeFeature branch

$ git checkout FEATURE/myAwesomeFeature

-> you end up in FEATURE/myAwesomeFeature branch

$ git branch -D feature/myAwesomeFeature branch

-> BOOM you just deleted the branch you were at. Congrats you repo is dirty again.

Actual behaviour:

It seems like checking out / deleting branches is case insensitive thus you can delete a branch you are on by just using a different capitalisation when specifying the branch to delete.

Expected behaviour:

error: Cannot delete the branch 'FEATURE/myAwesomeFeature' which you are currently on.

Thank you, please don't hesitate to contact me in case you need more info or if this has already been fixed in the meantime.

Cheers,
Marcus

Re: Bug: git branch -D can be used to delete branch which is currently checked out

[Junio C Hamano]

Marcus Kida <marcus.kida@gmail.com> writes:

> Testes on: 
>
> Mac OS X 10.11.3 (El Capitan) using Git 2.6.4
>
> Issue:
>
> git branch -D can be used to delete branch which is currently checked out

There are other limitations a filesystem that is incapable of
differentiating two files with names that are only different in case
imposes on your use of Git, e.g.

 - "git fetch origin", when the origin repository has two tags 'v1'
   and 'V1', may not let you have both of these tags locally;

 - "git checkout Another", when the branch you have is 'another',
   may check it out instead of complaining (replace "checkout" with
   any other command that let you use a refname to specify an object).

It is a possibility to teach the files backend of refs API that some
filesystems are case insensitive and do something special about them,
but I think in the longer term a more productive solution would be
to use the upcoming "pluggable ref backend" subsystem and either

 - use a backend that is not the "files" backend (e.g. lmdb backend,
   or the tree-object based backend);

 - add a variant of "files" backend but encodes the refnames in a
   way that is safe on case insensitive filesystems.

That way, those on platforms with case insensitive filesystems do
not have to be artificially limited.  Git is about working together
with people potentially on other systems, and "on this system you
cannot have 'master' and 'Master' at the same time, because we have
a patch to case-fold the refnames" would not be a good longer term
solution.

Re: Bug: git branch -D can be used to delete branch which is currently checked out

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> It is a possibility to teach the files backend of refs API that some
> filesystems are case insensitive and do something special about them,
> but I think in the longer term a more productive solution would be
> to use the upcoming "pluggable ref backend" subsystem and either
>
>  - use a backend that is not the "files" backend (e.g. lmdb backend,
>    or the tree-object based backend);
>
>  - add a variant of "files" backend but encodes the refnames in a
>    way that is safe on case insensitive filesystems.

A typofix s/but encodes/that encodes/ is needed to make this
sentence make any sense.  Sorry for a typo.

Just to elaborate a bit more, here is what I mean:

 - Thanks to recent work by David, Ronnie and Michael, we eradicated
   most if not all code that assume that the result of checking
   "test -f .git/refs/heads/foo" tells us if a branch 'foo' exists
   [*1*].  They all go through the API designed to allow different
   backends to access refs.

 - The traditional code that implemented 'foo' branch as writing a
   file '.git/refs/heads/foo' has been moved to a "files" backend.
   When used on a platform with case insensitive filesystem, it can
   answer "it exists" when asked about a branch 'Foo' (notice the
   case difference).

 - We could add a new backend that is still based largely on the
   existing "files" backend code, but stores 'foo' branch as a file
   ".git/refs/6865616473/666f6f" while storing another branch 'Foo'
   as ".git/refs/6865616473/466f6f" (I just used byte values in hex
   in this example, but of course you can use a more efficient and
   mostly human readable representations).

That way, even on a platform with case insensitive filesystem, you
do not have to worry about getting confused by the filesystem when
you have 'foo' and 'Foo' branches.


[Footnote]

*1* This is not strictly true even in the pre-pluggable ref backend
    world, as your refs may appear in the packed-refs file, but this
    detail does not matter in the larger picture.

Re: Bug: git branch -D can be used to delete branch which is currently checked out

[Marcus Kida]

Thank you,
I get your point.

Well this proposed solution will exceed my current knowledge of the git code at this point. (Which is basically null because I've never built it before)

> On 11 Mar 2016, at 5:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> It is a possibility to teach the files backend of refs API that some
>> filesystems are case insensitive and do something special about them,
>> but I think in the longer term a more productive solution would be
>> to use the upcoming "pluggable ref backend" subsystem and either
>> 
>> - use a backend that is not the "files" backend (e.g. lmdb backend,
>>   or the tree-object based backend);
>> 
>> - add a variant of "files" backend but encodes the refnames in a
>>   way that is safe on case insensitive filesystems.
> 
> A typofix s/but encodes/that encodes/ is needed to make this
> sentence make any sense.  Sorry for a typo.
> 
> Just to elaborate a bit more, here is what I mean:
> 
> - Thanks to recent work by David, Ronnie and Michael, we eradicated
>   most if not all code that assume that the result of checking
>   "test -f .git/refs/heads/foo" tells us if a branch 'foo' exists
>   [*1*].  They all go through the API designed to allow different
>   backends to access refs.
> 
> - The traditional code that implemented 'foo' branch as writing a
>   file '.git/refs/heads/foo' has been moved to a "files" backend.
>   When used on a platform with case insensitive filesystem, it can
>   answer "it exists" when asked about a branch 'Foo' (notice the
>   case difference).
> 
> - We could add a new backend that is still based largely on the
>   existing "files" backend code, but stores 'foo' branch as a file
>   ".git/refs/6865616473/666f6f" while storing another branch 'Foo'
>   as ".git/refs/6865616473/466f6f" (I just used byte values in hex
>   in this example, but of course you can use a more efficient and
>   mostly human readable representations).
> 
> That way, even on a platform with case insensitive filesystem, you
> do not have to worry about getting confused by the filesystem when
> you have 'foo' and 'Foo' branches.
> 
> 
> [Footnote]
> 
> *1* This is not strictly true even in the pre-pluggable ref backend
>    world, as your refs may appear in the packed-refs file, but this
>    detail does not matter in the larger picture.
> 
>