RFC: reflog for deleted branches

RFC: reflog for deleted branches

[Sven Strickroth]

Hi,

an often heart question is how to restore deleted branches. Sometimes
those can be restored by using the reflog of the HEAD.

But why not create a special (ref)log for deleted branches (with SHA1,
date, name of the branch and maybe commit message of the last commit on
the deleted branch)? This way people could just look up the SHA1 of the
deleted branch and can recreate it (even if they moved the HEAD around a
lot).

-- 
Best regards,
 Sven Strickroth
 ClamAV, a GPL anti-virus toolkit   http://www.clamav.net
 PGP key id F5A9D4C4 @ any key-server

Re: RFC: reflog for deleted branches

[Junio C Hamano]

Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:

> an often heart question is how to restore deleted branches. Sometimes
> those can be restored by using the reflog of the HEAD.
>
> But why not create a special (ref)log for deleted branches (with SHA1,
> date, name of the branch and maybe commit message of the last commit on
> the deleted branch)? This way people could just look up the SHA1 of the
> deleted branch and can recreate it (even if they moved the HEAD around a
> lot).

The itch is legit, but I doubt a "special log for deleted branches" is a
good design.  Why do you limit yourself only to a single "last" commit?
Wouldn't it be a better design to save away the entire reflog for the
branch when a branch is deleted, possibly with expedited expire rule for
such a reflog?

Re: RFC: reflog for deleted branches

[Sven Strickroth]

Am 03.05.2012 23:37 schrieb Junio C Hamano:
> The itch is legit, but I doubt a "special log for deleted branches" is a
> good design.  Why do you limit yourself only to a single "last" commit?

That was just the first idea ;)

> Wouldn't it be a better design to save away the entire reflog for the
> branch when a branch is deleted, possibly with expedited expire rule for
> such a reflog?

The "normal" reflog cannot be used if you just create and then delete a
branch - the reflog is empty in this case. A special "deleted" entry
pointing to the SHA1 of the branch is needed. Also the question is how
to handle the case that a user creates and deletes a new branch with the
same name.

All in all, I (and lots of other users) would be happy if this issue
could be addressed in one of the next releases. :)

-- 
Best regards,
 Sven Strickroth
 ClamAV, a GPL anti-virus toolkit   http://www.clamav.net
 PGP key id F5A9D4C4 @ any key-server

Re: RFC: reflog for deleted branches

[Andrew Sayers]

On 03/05/12 22:25, Sven Strickroth wrote:
> Hi,
> 
> an often heart question is how to restore deleted branches. Sometimes
> those can be restored by using the reflog of the HEAD.
> 
> But why not create a special (ref)log for deleted branches (with SHA1,
> date, name of the branch and maybe commit message of the last commit on
> the deleted branch)? This way people could just look up the SHA1 of the
> deleted branch and can recreate it (even if they moved the HEAD around a
> lot).
> 

Something like this may well be needed by an SVN importer, as it's quite
possible for an SVN branch to be deleted, then another branch forked
from it years later.  See the (brief) discussion here:

http://article.gmane.org/gmane.comp.version-control.git/195517
http://article.gmane.org/gmane.comp.version-control.git/195544

This is really Florian's area, but I expect it would be easy enough for
SVN import to build on top of any reasonably general solution if you're
offering :)

	- Andrew

Re: RFC: reflog for deleted branches

[Junio C Hamano]

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?

Re: RFC: reflog for deleted branches

[Sven Strickroth]

Am 04.05.2012 01:05 schrieb Junio C Hamano:
> 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?

I suppose an entry for deletion should be sufficient.

-- 
Best regards,
 Sven Strickroth
 ClamAV, a GPL anti-virus toolkit   http://www.clamav.net
 PGP key id F5A9D4C4 @ any key-server

Re: RFC: reflog for deleted branches

[Sitaram Chamarty]

On Fri, May 4, 2012 at 2:55 AM, Sven Strickroth
<sven.strickroth@tu-clausthal.de> wrote:
> Hi,
>
> an often heart question is how to restore deleted branches. Sometimes
> those can be restored by using the reflog of the HEAD.

I get by with:

    gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3
-d' ') --not --branches --tags --remotes

Works for me because I usually remember *something* about the commit
message so then I type in "/" and the string and in a few
"Shift-downarrow"s I'm there.

Re: RFC: reflog for deleted branches

[Robin Rosenberg]

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. One way would be
to append a "." to the leaf in the refs directory tree. Older readers
wouldn't understand that to there's a compatibility issue.

-- robin

Re: RFC: reflog for deleted branches

[Junio C Hamano]

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

> 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.