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

Junio C Hamano [off-list ref] 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.

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 [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

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.