Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 11, 2012, 13:40 UTC
Message-ID: <20120111134011.GH32173@burratino>
In-Reply-To: <CALkWK0mv2jzmDA==pJg5R4jH0yxo=OopYM_WzAWusiffnb+4HQ@mail.gmail.com>

Ramkumar Ramachandra wrote:

> We'd be prematurely locking ourselves into a design where we can't
> tell which top-level command issued the continue/ abort

The .git/sequencer/todo file already doesn't record which top-level command initiated the sequence and doesn't seem to operate under a model in which that is a useful question. Honestly, that's my only objection to the "git revert --continue during git cherry-pick" check.

I think it is not premature to think about whether that matters. I've already said a little about related cases where it seemed to matter but there was instead something else at play. Can you offer some examples of how people might use the "git cherry-pick" / "git revert" commands and get stuck or run into trouble, and how git can help them?

[...]

>                                                           My sincere
> suggestion is to procrastinate the problem until we have a tighter
> usecase (a new top-level command or action added, for instance).

Thinking carefully about sequencer use cases also seems like a good idea. Is it intended that "git am" and "git rebase" should be reimplemented on top of the sequencer? Do you have goals in mind for commands like "git sequence --step" that could be used to examine, influence, and carry out git's idea of what should happen next?

If we have no use case, then there's no reason to change the code. It already works[*] for cherry-pick and revert. I think we shouldn't be moving this code to sequencer.c or cleaning up the API to suit other commands (e.g., introducing two ways to sane "am I picking or reverting") without having one in mind.

[*] Modulo bugs and some missing features such as --skip.