Re: [PATCH v2 5/5] Reftable support for git-core
- From
Jeff King <peff@peff.net>
- Date
- Jan 29, 2020, 08:12 UTC
- Message-ID
- <20200129081259.GB601903@coredump.intra.peff.net>
- In-Reply-To
- <2215899.n3y15ba4yI@mfick-lnx>
On Tue, Jan 28, 2020 at 08:36:53AM -0700, Martin Fick wrote:
Show 11 quoted lines
> > There's a slight downside in that tools which _aren't_ careful about > > repositoryformatversion might try to operate on the repository, writing > > into refs/ or whatever. But such tools are broken, and I'm not sure we > > should be catering to them (besides which, the packed-refs ship sailed > > long ago, so they're already potentially dangerous). > > Could you elaborate on this a bit because it seems on the surface that these > tools aren't very dangerous, and therefore likely many of them exist? > > What are the dangers today of tools that understand/operate on loose and > packed refs without reading repositoryformatversion?
I was mostly thinking of hacky scripts that tried to touch .git/refs directly. And there are a few levels of dangerous there:
- if you're doing "echo $sha1 >.git/refs/heads/master", then you're
not locking properly. But it would probably work most of the time. - if you're properly taking a lock on ".git/refs/heads/master.lock"
and renaming into place but not looking at packed-refs, then you
might overwrite somebody else's update which is in the packed file - if you're trying to read refs and not reading packed-refs, obviously
you might miss some valuesIf you're actually doing the correct locking and packed-refs read (which "real" implementations like libgit2 do) then no, I don't think that's dangerous. And I think libgit2 properly complains when it sees a repositoryformatversion above 0. I don't know offhand about JGit, or any of the lesser-used ones like dulwich or go-git.
-Peff