Race condition in git-bundle(1) create when ref is updated while running

Hi y'all,

I discovered a bug in git-bundle(1) create. There is a race condition happening when a ref gets updated while the bundle creation process is running.

To reproduce, I've been running git-bundle(1) with
create my.bndl --all --ignore-missing in a debugger. I've set a breakpoint at bundle.c:515[1] where setup_revisions() is called. After stepping over this line I see in the debugger revs.pending is populated.

(gdb) p *revs.pending.objects
$6 = {item = 0x7a2fb0, name = 0x78d7e0 "refs/heads/master", path = 0x0, mode = 12288}
(gdb) p *revs.pending.objects.item
$7 = {parsed = 1, type = 1, flags = 0, oid = {hash = "R\026\370\365\304\b\236\302\234\344\232\372\024t4\302>\017\001c\000\000\000\000sS\344\367\377\177\000", algo = 1}}

The hash value is the binary representation of 5216f8f5c4089ec29ce49afa147434c23e0f0163, the current HEAD of master. At this point I've updated master in another terminal window:

    git commit --allow-empty -m"dummy"

Then in the debugger I continue the process to create the bundle. The resulting bundle seems to be missing refs/heads/master.

I'm surprised this ref is completely omitted from the bundle. Even though the ref is outdated, I would expect git-bundle(1) to just take the old commit ID.

[1]: https://github.com/git/git/blob/5216f8f5c4089ec29ce49afa147434c23e0f0163/bundle.c#L515

--
Toon

"--all" that tells "traverse from the tip of all the refs" to any rev-list family of commands (like log and bundle) eventually boils down to opendir("refs/...") followed by readdir(), and if somebody creates or deletes files while you are reading in such a loop, readdir() may appear to skip an entry, which is understandable. Even "git for-each-ref" would race with a ref update (which involves removing a file and then creating another file at the same path), I would think. IOW, I do not think this is limited to "git bundle".

Yeah, it's unfortunately a general issue with the "files" backend and nothing that can easily be solved there. The only answer I can provide in this context is that the "reftable" backend will fix it because it enables consistent reads -- sorry for this shameless plug.

Patrick