Re: Bug: git branch -D can be used to delete branch which is currently checked out
- From
Marcus Kida <marcus.kida@gmail.com>
- Date
- Mar 10, 2016, 18:38 UTC
- Message-ID
- <1592384A-0415-447A-B684-203871594E28@gmail.com>
- In-Reply-To
- <xmqqfuvydwf5.fsf@gitster.mtv.corp.google.com>
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)
Show 51 quoted lines
> 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. > >