Re: RFC: reflog for deleted branches

From: Junio C Hamano <gitster@pobox.com>
Date: May 4, 2012, 16:24 UTC
Message-ID: <7vmx5nc3sc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FA376B5.50804@dewire.com>

Robin Rosenberg <robin.rosenberg@dewire.com> writes:

Show 14 quoted lines

> Junio C Hamano skrev 2012-05-04 01.05:
>> Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
>>
>>> The "normal" reflog cannot be used if you just create and then delete a
>>> branch - the reflog is empty in this case.
>>
>> I somehow thought we discussed about the lack of "creation" event.
>> Perhaps it is sufficient to create a reflog entry for such then?
>
> We have the create event (oldd=0000...), if we just don't delete the log and add
> a destroy event (newid=000000).
>
> A bit trickier with the current reflog design is the case where you
> delete branch foo and then create the branch foo/bar.

That is not worth worrying about from the behavioral point of view, as end users, even on Macs and Windows, have long learned that in a hierarchical name space, you cannot have foo and foo/bar at the same time. But from the implementation point of view, that implies in this sequence:

	create foo/bar, creating refs/heads/foo/bar and logs/foo/bar
        delete foo/bar, removing refs/heads/foo/bar but keeping logs/foo/bar
	create foo

the third step needs to "rm -fr logs/foo && >logs/foo". We have refs/heads/foo under lock, so presumably nobody can create a baz branch that adds logs/foo/baz to race with us while we do so, but I didn't check. Our lock taking code may need to be tweaked so that if you take lock on refs/heads/foo, nobody else can take lock on refs/heads/foo/anything, and vice versa.