All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.