Re: [PATCH v11 35/41] refs.c: pack all refs before we start to rename a ref

[Jonathan Nieder <jrnieder@gmail.com>]

Ronnie Sahlberg wrote:

> We want to do this to make it easier to handle atomic renames in rename_ref for
> 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 not
> exist as a loose ref we can avoid locking foo/bar.lock during transaction
> commit

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
it runs.

> Signed-off-by: Ronnie Sahlberg <sahlberg@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 <jrnieder@gmail.com>