Re: [PATCH 0/7] New sequencer workflow!

Junio C Hamano <gitster@pobox.com> writes:

To clarify a bit.

While I do not mind "sequencer --continue" as a step to get us closer to a more pleasant user experience at the implementation level, exposing the name "sequencer" or having the user to type "sequencer --continue" is going in a very wrong direction at the UI level.

There are many commands in the Git suite that take an order from the user, attempt to perform the necessary operation but stops in the middle to ask for help from the user. "cherry-pick" and "revert" are two of them, and there are many others: e.g. am, merge, pull, rebase, "rebase -i". They use different mechanisms to keep track of their states before giving the control back to the user when they ask for help.

The original workflow was "pull; edit && add && commit", and it is very unlikely this will change while we are still in Git 1.X series. The original single commit variants of "cherry-pick" and "revert" are in the same category. We would need to keep supporting "cherry-pick/revert; edit && add && commit" as a workflow for a while.

Others that deal with more than one stop-point follow a different pattern from necessity. The user tells the same command to continue after the command asks for help in "am; edit && add && am --continue" and "rebase [-i]; edit && add && rebase --continue" sequence. Multi-commit variants of "cherry-pick" and "revert" take the same approach for consistency.

In the shorter term, a person new to Git, after learning "run command X, X gives back control asking for help, help X by editing and adding, and telling X to continue" pattern from these commands, will eventually find that the commands in single stop-point category (i.e. "pull", "merge" and single-commit "cherry-pick" and "revert") inconsistent from others that take "--continue" to resume. For this reason, "git cherry-pick --continue" that would work even when picking a single commit like this would be beneficial:

    $ git cherry-pick X
    ... conflicts
    $ edit && add
    $ git cherry-pick --continue

That is, no "commit" by the user. The "helping" part is literally that; the user helps Git because Git is too stupid to read the user's mind to come up with a perfect conflict resolution. Git knows, given a correct resolution, how to make a commit out of it perfectly fine and does not need help from the user to commit the result.

In the medium term, extending the above "shorter term" goal, it would make sense to support (but not necessarily require) the following flow for consistency:

    $ git pull ;# or "git merge branch"
    ... conflicts
    $ edit && add ;# again, no "commit"
    $ git pull --continue ;# or "git merge --continue"

Now, if you rename "cherry-pick --continue" and "revert --continue" to "sequencer --continue", what message are you sending to the users? They now need to learn that only these two commands are based on something called "sequencer", can be resumed with "sequencer --continue", but other commands need to be continued with "X --continue".

That is totally backwards, no? You are _adding_ mental burden to your users by introducing another thing or two they need to learn about.

In the longer term (now we are talking about Git 2.X version bump), it would be ideal if all the "git X --continue" can be consolidated to a single "git continue" command (and "git abort" to give up the sequence of operations).

Given that bash-completion script can tell in what state the repository is, I think this is doable. "git continue" may invoke your implementation of "git sequencer --continue" internally when it detects that the state is something the "sequencer" machinery knows how to continue, and if it is in the middle of conflicted "am -3" or rejected "am", the command may invoke "git am --continue" instead.

That way, the user does not have to learn which command can be resumed with "sequencer --continue" and which other command needs to be called with "--continue" to resume. The user does not even need to know there is a mechanism called sequencer, some commands are already using it while others are not yet using it, and these other commands are in the process of being rewritten to use the sequencer machinery.