From: Junio C Hamano <gitster@pobox.com>
To: Marcus Kida <marcus.kida@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Bug: git branch -D can be used to delete branch which is currently checked out
Date: Thu, 10 Mar 2016 10:23:26 -0800 [thread overview]
Message-ID: <xmqqfuvydwf5.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqvb4udyf9.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Thu, 10 Mar 2016 09:40:10 -0800")
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.
next prev parent reply other threads:[~2016-03-10 18:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 8:20 Bug: git branch -D can be used to delete branch which is currently checked out Marcus Kida
2016-03-10 17:40 ` Junio C Hamano
2016-03-10 18:23 ` Junio C Hamano [this message]
2016-03-10 18:38 ` Marcus Kida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqfuvydwf5.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=marcus.kida@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.