From: Phillip Wood <phillip.wood123@gmail.com>
Date: Tue, 25 Jun 2019 13:25:25 GMT
Subject: Re: Git status parse error after v.2.22.0 upgrade
Message-ID: <82f4aa37-51fa-4d1a-8221-d6dd37113c70@gmail.com>
In-Reply-To: <8981e6c8-eb20-fde7-2b4c-1fbf2057caef@gmail.com>

On 13/06/2019 18:43, Phillip Wood wrote:
> On 13/06/2019 17:24, Jeff King wrote:
>> On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:
>>>
>>> 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?
> 
> I think the commit Junio is referring to is
> b07d9bfd17 ("commit/reset: try to clean up sequencer state", 2019-04-16)
> which will only remove the sequencer directory if it stops after the
> pick was the last one in the series. The idea is that if cherry-pick
> stops for a conflict resolution on the last pick user commits the result
> directly or run reset without running `cherry-pick --continue`
> afterwards the sequencer state gets cleaned up properly.
> 
>> 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.
> 
> Now that we try harder to clean up the sequencer state I wonder if that
> would just cover up bugs where the state has not been removed when it
> should have been.

When I wrote that it hadn't dawned on me that if there is an error the 
status will not tell the user that a cherry-pick is in progress which is 
what we really want so they are alerted to the stale sequencer state. 
I've posted a series [1] to address this (sadly gitgitgadget wont let me 
post it on this thread).

Best Wishes

Phillip

[1] 
https://public-inbox.org/git/pull.275.git.gitgitgadget@gmail.com/T/#mf57a4ab95ba907fbf2d06ec64e9b676db158eace


> That can lead to unpleasant problems if the user
> aborts a single revert/cherry-pick when there is stale sequencer state
> around as it rewinds HEAD to the commit when the stale
> cherry-pick/revert was started as explained in the message to b07d9bfd17
> ("commit/reset: try to clean up sequencer state", 2019-04-16)
> 
> If we do want to do something then maybe teaching gc not to collect
> commits listed in .git/sequencer/todo and
> .git/rebase-merge/git-rebase-todo would be useful.
> 
> Best Wishes
> 
> Phillip
> 
>> -Peff
>>
>