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@xxxxxxxxxx> > --- > 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@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html