Ronnie Sahlberg wrote:
> We want to do this to make it easier to handle atomic renames in rename_ref
> the case 'git branch -m foo/bar foo'.
In an ideal world, a part of me would rather see "git branch -m" doing
something more targeted by only packing the two refs it is working
with, and only when it knows it has to so the normal "git branch -m
foo bar" case doesn't have to suffer. But:
That would be more complicated.
Packing refs is not very slow and has some good benefits for
performance of later commands. Once we've committed to writing out a
new pack-refs file, it's not so bad to enumerate all loose refs to get
more benefit from writing out the new packed-refs file.
Renaming refs is something usually done by humans and not by scripts
or remote clients. I'm not too worried about "git branch -m" in a
tight loop getting slower.
So I think this is an okay thing to do.
> If we can guarantee that foo/bar does
> exist as a loose ref we can avoid locking foo/bar.lock during transaction
That is not quite true --- there's still value in locking foo/bar to
avoid clobbering a concurrent ref update.
If git performed the entire rename transaction in the packed-refs
file, we could avoid that race completely (for 'git branch -m foo/bar
foo': lock refs, make sure the loose refs are pruned, perform the
update in packed-refs, unlock refs. for 'git branch -m foo foo/bar':
lock foo, prune foo, lock foo/bar, prune foo/bar, perform the update
in packed-refs, unlock refs).
Even without doing that, packing refs first has a benefit in terms of
ordering: if you do (1) delete loose foo/bar, (2) write loose foo, (3)
rewrite packed-refs without foo/bar, then because you've packed refs
first, no objects become unreferenced during step (1), which means
that a hypothetical version of "git gc" that used filesystem snapshots
would not see any relevant objects as safe to clean up no matter when
> Signed-off-by: Ronnie Sahlberg <sahlb...@google.com>
> refs.c | 3 +++
> t/t3200-branch.sh | 6 +++---
> 2 files changed, 6 insertions(+), 3 deletions(-)
With a clearer commit message,
Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html