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@xxxxxxxxx/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
