mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Casey Meijer <>
To: "brian m. carlson" <>
Cc: "" <>
Subject: Re: BUG FOLLOWUP: Case insensitivity in worktrees
Date: Fri, 24 Jul 2020 18:14:03 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

I think I misunderstood your claim actually Brian.   What is a bug is asking for worktree A's head and getting the main worktree's head. A super dangerous bug. 

I certainly disagree with your assertion that asking for head and not getting HEAD (or HeaD or hEAd) on a case-insensitive storage engine isn't a bug and it certainly 
shouldn't be a bug once extensible storage engines are in place: the storage engine should have final say on how objects are stored and retrieved, not git-core. 



On 2020-07-23, 10:19 PM, "brian m. carlson" <> wrote:

    On 2020-07-23 at 15:20:50, Casey Meijer wrote:
    > This just bit me; it seems quite old, and I wanted to propose an alternative solution (maybe it doesn’t work for some reason I’m unaware of):
    > Why not just preserve the existing semantics of the main worktree by checking the worktree refs first unconditionally and only fall back to the main refs when the ref doesn’t exist locally in the worktree?
    > This would have the added benefit of allowing power users to override refs in their worktrees and would, if I’m not mistaken, preserve the semantics of the main worktree in case-insensitive and case-sensitive filesystems.

    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?

    > Anywho, just a thought.  I could work on a patch if this approach makes sense at least as an intermediary until there’s a pluggable storage backend for non-FS stores 😉   (I'd also be somewhat interested in implementing a postgres/sql storage backend if this project is moving forwards __ ).

    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.
    brian m. carlson: Houston, Texas, US

  parent reply	other threads:[~2020-07-24 18:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2020-07-23 15:20 ` BUG FOLLOWUP: Case insensitivity in worktrees 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
2020-07-24 18:17       ` Casey Meijer
2020-07-24 19:36         ` Junio C Hamano
2020-07-24 18:14     ` Casey Meijer [this message]
2020-07-24 21:09       ` brian m. carlson

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:

  List information:

* 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 public 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).