Re: [PATCH 08/10] contrib: remove "git-resurrect.sh"

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Tue, May 6, 2025, at 22:11, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
>> The "git-resurrect.sh" script can be used to find traces of a branch tip
>> in the reflog and resurrect that branch. Despite a couple of global
>> cleanups, the script hasn't seen any activity since it was introduced in
>> e1ff064e1bf (contrib git-resurrect: find traces of a branch name and
>> resurrect it, 2009-02-04).
>
> A single-purpose thing that is done correctly on top of a right
> abstraction does not necessarily need further updates, so I doubt
> this paragraph contributes to the decision to remove the script in
> any way.
>
> Having said that, I would not be surprised at all if large bugs
> still remain in the script.  The reason why we scarcely heard
> complaints about it is due to the fact that people simply are not
> aware of it, people do not lose branches too often, and when it
> happens, it is crystal clear what needs to be done with the output
> of "git reflog HEAD@{0}", once people learn about "git reflog".
> Even though it may be tedious to inspect "git reflog" output and
> pick the right record to use with "git branch" to resurrect, as long
> as it is a one-off thing, it would be more assuring to end-users than
> some rarely used script with no correctness guarantee magically picks
> a commit to place on the "resurrected" branch tip, I suspect.

The top-voted answer here has 3029 votes:
https://stackoverflow.com/a/3640806/

Which is in fact to just use the reflog manually.

The git-resurrect.sh answer was added two days later and has 16 votes:
https://stackoverflow.com/a/3653931/

Given this vote-split,[1] it seems people would rather do some manual
reflog work rather than figure out how to call scripts from contrib/.

Also the answer was by Jakub Narębski.  (Not a normal user who happened
to find contrib/)

It seems that many people delete branches they would like back at least
one time during their tenure.  But they don’t seem to want to streamline
that process.  Which makes sense considering the previous discussion
here.

† 1: Potentially popular answers can get buried on StackOverflow if they
    are posted much later.  But this does not seem to be the case here.

    Also a 337 vote answer was posted over three years later.[1]
    Although that’s a more advanced answer which goes into using
    git-fsck(1).

    [2]: https://stackoverflow.com/a/22303923/