[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v11 35/41] refs.c: pack all refs before we start to rename a ref
From:       Jonathan Nieder <jrnieder () gmail ! com>
Date:       2014-05-30 18:08:15
Message-ID: 20140530180815.GI12314 () google ! com
[Download RAW message or body]

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