Re: Git status parse error after v.2.22.0 upgrade

From: Jeff King <peff@peff.net>
Date: Jun 13, 2019, 16:24 UTC
Message-ID: <20190613162432.GA12128@sigill.intra.peff.net>
In-Reply-To: <xmqqr27xwjwj.fsf@gitster-ct.c.googlers.com>

On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:

Show 24 quoted lines

> aleksandrs@ledovskis.lv writes:
> 
> > My repo indeed contains a ".git/sequencer/todo" file which
> > contains references to commits long-gone (i.e., rebased).
> > Renaming or deleting this file stops whines about "error: could
> > not parse".
> 
> Interesting.  So in short, when the repository has leftover
> sequencer state file that is not in use, "git status parse" thing
> (whatever it is---are you getting it when you run "git status"
> command???)---is not careful enough to notice that it does not
> matter even if that leftover file is unusable.
> 
> Two issues "the sequencer" folks may want to address are
> 
>  (1) make the one that reads an irrelevant/stale 'todo' file more
>      careful to ignore errors in such a file;
> 
>  (2) make the sequencer machinery more careful to clean up after it
>      is done or it is aborted  (for example, "git reset --hard"
>      could remove these state files preemptively even when a rebase
>      is not in progress, I would think).
> 
> I think we already had some patches toward the latter recently.

Maybe I am not understanding it correctly, but do you mean in (2) that "git reset --hard" would always clear sequencer state? That seems undesirable to me, as I often use "git reset" to move the head around during a rebase. (e.g., when using "rebase -i" to split apart I commit, I stop on that commit, "git reset" back to the parent, and then selectively "add -p" the various parts).

Direction (1) seems quite sensible to me, though.

-Peff