On Tue, May 06, 2025 at 01:11:37PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> 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.
>
> So I personally do not think many people shed tears if we remove
> this script. I am for its removal.
>
> Do we have a better alternative we officially support, by the way?
Not that I'd know of, no, but I also had the same thought. If this was a
common scenario then we really should provide an easy user interface for
it. The question is whether it does come up often.
In any case, the best solution from my perspective would be to stop
deleting reflogs for deleted branches, even if only for the reftable
backend. We don't have to worry about file/directory conflicts there, so
there isn't really a good reason why reflogs need to be deleted with
their branch. I would even say that it's counter to the intent to
reflogs in the first place: the intent is to restore old versions of a
specific reference, and I cannot see a good reason why a user wouldn't
want to do that even for deleted refs.
If we did that, a user can trivially learn about the old state of that
branch (and even states before!) even after they have accidentally
deleted it. Just type `git reflog show refs/heads/branch` and you got
it. There wouldn't even be any extra need for a new command, this feels
simple enough to me.
Patrick
