From: Casey Meijer <firstname.lastname@example.org>
To: Junio C Hamano <email@example.com>,
"brian m. carlson" <firstname.lastname@example.org>
Cc: "email@example.com" <firstname.lastname@example.org>
Subject: Re: BUG FOLLOWUP: Case insensitivity in worktrees
Date: Fri, 24 Jul 2020 18:07:29 +0000 [thread overview]
Message-ID: <5352321F-0122-49BA-B778-80A84DDABB71@strongestfamilies.com> (raw)
It's definitely a bug and it's kind of amazing that it's been floating about for 2 years.
I'm not suggesting anything really change except the way you determine whether a ref is "work-tree local" or not.
This way on case sensitive filesystems only HEAD will be accepted, and on case insensitive filesystems both head and HEAD
will be valid (and will refer to the same file/ref), replicating the semantics of the primary worktree.
Namely, instead of checking explicitly for "HEAD" (or going through some hoops to determine if the filesystem
*is* case sensitive), just look in the worktree refs. If it's in there, then it's worktree local. If not, then not.
Like I said, maybe there are some problems with this approach that I'm not aware of, but if so, I think it's worth thinking
about whether those problems are resolvable 😊
As far as alternate storage engines, I'd be more interested in seeing core git builtout to support a plugable storage engine than any specific implementation.
Take a look at PostgreSQL's work on Table Access Methods for an example in this vein. I think this idea plays well with my proposal above as well because it
delegates the responsibility of case sensitivity to the storage backend (in this case, the filesystem).
On 2020-07-23, 10:25 PM, "Junio C Hamano" <email@example.com> wrote:
"brian m. carlson" <firstname.lastname@example.org> writes:
> It isn't clear to me exactly what you're suggesting. Are you suggesting
> that we allow "head" instead of "HEAD" in worktrees, or that we allow
> refs in general to be case insensitive, or something else?
> There is a proposal for a ref storage backend called "reftable" which
> will not store the ref names in the file system, and work is being done
> on it. There has been a suggestion for an SQLite store in the past, but
> that causes problems for certain implementations, such as JGit, which do
> not want to have C bindings.
Yes, another important thing to point out is that one shared goal of
these efforts is so that users, even those on case insensitive
filesystems, can name their refs foo and FOO and have the system
treat these as two distinct refs. IOW, wanting to enhance "support"
for case insensitive treatment of refs will not fly---asking for
"head" and getting contents of "HEAD" on certain platforms is a bug,
induced by limited filesystem these platforms use, and it is being
next prev parent reply other threads:[~2020-07-24 18:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <EEA65ED1-2BE0-41AD-84CC-780A9F4D9215@strongestfamilies.com>
2020-07-23 15:20 ` Casey Meijer
2020-07-24 1:19 ` brian m. carlson
2020-07-24 1:25 ` Junio C Hamano
2020-07-24 18:07 ` Casey Meijer [this message]
2020-07-24 18:17 ` Casey Meijer
2020-07-24 19:36 ` Junio C Hamano
2020-07-24 18:14 ` Casey Meijer
2020-07-24 21:09 ` brian m. carlson
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this inbox:
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).