Thanks!
On Fri, May 30, 2014 at 11:08 AM, Jonathan Nieder <jrnie...@gmail.com> 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 <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
