Jeff King <peff@xxxxxxxx> wrote: > Yeah, I think there's sort of an open question here of who is calling > update-server-info when nothing got updated. I think the only place we > call it automatically is via receive-pack, but I'd guess Eric runs it as > part of public-inbox scripts. Correct. post-update doesn't get run because public-inbox relies on fast-import. I have mirrors using "git fetch", which also doesn't call post-update, either so I was calling update-server-info in my mirror script. Since more people have taken an interest in mirroring things, I figured I'd make "public-inbox-index" (the script which updates the Xapian and SQLite indices) call update-server-info itself. That way, it's simpler to mirror (v1) inboxes: git fetch && git update-server-info && public-inbox-index becomes: git fetch && public-inbox-index That's a huge savings in cognitive overhead. So, my eventual goal for this is we get to the point where any git operation which changes refs will automatically update info/refs if it exists. Ditto for objects/info/packs on any pack changes. This, like my bitmap-by-default change is among the things I'm trying to make it easier for more users to start self-hosting (including mirroring) any type of git repo. Anyways, I am far from knowledgeable about the locking discussion for git, though :x > That's my reading, too, but I didn't want to be responsible for > regressing some obscure case. At least Eric seems to _use_ > update-server-info. ;) I also have something else on my mind for abusing info files with :> (another email)