Re: [RFH] sequencer: simplify logic around stopped-sha file

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Sat, 26 Sep 2020, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Is there something obvious I am not seeing that makes this change a
> >> bad idea (other than "somebody may be in the middle of a rebase and
> >> all of a sudden, version of Git gets updated to contain this one,
> >> which is unable to read abbreviated object name the current version
> >> left on disk", which I am deliberately ignoring)?
> >
> > [...]
> > - and most importantly: just like we expand the commit IDs in the todo
> >   list, we actually want to expand them in `stopped-sha` because it _is_
> >   possible that a new object is written that makes the previous
> >   unambiguously abbreviated object ID now ambiguous (e.g. when the user
> >   commits in a separate worktree while the rebase is interrupted, before
> >   continuing the rebase).
>
> Exactly.  I just wasn't sure if stopped-sha is handled with the same
> carefulness as the object names in todo, which are expanded after
> read and shortened before given back to the users.

The main purpose of `stopped-sha` is to let `git rebase --continue` after
an `edit` command amend the commit where it stopped _iff_ it is still
`HEAD`.

So yes, I think we need to be as careful here.

Ciao,
Dscho