Re: Git status parse error after v.2.22.0 upgrade
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Jun 25, 2019, 13:25 UTC
- 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:
Show 37 quoted lines
> 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
Show 17 quoted lines
> 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
>>
>