From: Patrick Steinhardt <ps@pks•im>
To: Junio C Hamano <gitster@pobox•com>
Cc: "brian m. carlson" <sandals@crustytoothpaste•net>,
Karthik Nayak <karthik.188@gmail•com>,
K Jayatheerth <jayatheerthkulkarni2005@gmail•com>,
ryenus@gmail•com, git@vger•kernel.org
Subject: Re: Re [bug] pull --prune could not delete references due to lock file already exists error
Date: Tue, 1 Jul 2025 12:31:06 +0200 [thread overview]
Message-ID: <aGO46urHzZTZvDve@pks.im> (raw)
In-Reply-To: <xmqq1pr1lyur.fsf@gitster.g>
On Mon, Jun 30, 2025 at 02:10:36PM -0700, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste•net> writes:
>
> > Another option is for users on case-insensitive systems to use reftable,
> > which won't have the same problems as the file-based backend and will
> > preserve case properly.
>
> The more guinea-pigs^Wadopters we have, the merrier we are ;-).
I'd really like to start thinking about reftables as the default
backend. They fix filesystem-specific issues, compress better, are more
efficient in most (not all) use cases, sometimes significantly so, have
better properties when it comes to repository maintenance. We could for
example make "features.experimental" enable the reftable backend by
default and add a note to the Git 3.0 breaking changes in that spirit.
I'm quite certain that reftables are stable enough to not cause any
problems as used via Git. We have it rolled out to a couple hundred
thousand of repositories on our staging systems at GitLab, and will soon
roll them out to production systems. I myself have been running with
reftables for 1.5 years now and haven't seen a bug after the first
couple months.
But the bigger issue unfortunately is the ecosystem. JGit supports
reftables, but other implementations like libgit2 and Gitoxide don't. I
partially got myself to blame here, because I haven't gotten around to
updating the libgit2 pull request and am lacking the time to finish that
one. So it's probably a non-starter if all tools that use those libraries
cannot access such reftable-enabled Git repositories at all anymore.
I bet there's also tons of scripts out there that just reach into the
filesystem to do stuff, but that's something that we cannot really help
with.
Too bad :/
Patrick
next prev parent reply other threads:[~2025-07-01 10:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 12:32 [bug] pull --prune could not delete references due to lock file already exists error ryenus
2025-06-25 14:18 ` Re " K Jayatheerth
2025-06-27 18:59 ` brian m. carlson
2025-06-30 7:26 ` JAYATHEERTH K
2025-06-30 13:46 ` Karthik Nayak
2025-06-30 14:20 ` brian m. carlson
2025-06-30 21:10 ` Junio C Hamano
2025-07-01 10:31 ` Patrick Steinhardt [this message]
2025-07-01 16:14 ` Junio C Hamano
2025-07-02 8:50 ` Patrick Steinhardt
2025-07-01 8:20 ` Karthik Nayak
2025-07-02 4:50 ` Chris Torek
2025-07-02 15:37 ` Junio C Hamano
2025-07-01 0:52 ` JAYATHEERTH K
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=aGO46urHzZTZvDve@pks.im \
--to=ps@pks$(echo .)im \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jayatheerthkulkarni2005@gmail$(echo .)com \
--cc=karthik.188@gmail$(echo .)com \
--cc=ryenus@gmail$(echo .)com \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox