Re: [PATCH v11 35/41] refs.c: pack all refs before we start to rename a ref

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks!

On Fri, May 30, 2014 at 11:08 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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 <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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]