Re: Re [bug] pull --prune could not delete references due to lock file already exists error

From: Patrick Steinhardt <ps@pks.im>
Date: Jul 1, 2025, 10:31 UTC
Message-ID: <aGO46urHzZTZvDve@pks.im>
In-Reply-To: <xmqq1pr1lyur.fsf@gitster.g>

On Mon, Jun 30, 2025 at 02:10:36PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> "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