On Fri, May 30, 2014 at 11:08 AM, Jonathan Nieder <> wrote:
> 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 <>
>> ---
>>  refs.c            | 3 +++
>>  t/ | 6 +++---
>>  2 files changed, 6 insertions(+), 3 deletions(-)
> With a clearer commit message,
> Reviewed-by: Jonathan Nieder <>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to