Thanks!
On Fri, May 30, 2014 at 11:08 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 53 quoted lines
> 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>
Ronnie Sahlberg <sahlberg@google.com>