Jeff King p...@peff.net writes:
... Knowing what each state _means_
and what operations are meaningful to perform is much trickier (e.g., if
we are in a rebase, you probably do not want to start a new rebase. But
is it wrong to cherry-pick?).
It would be nice if we could find a way to generalize in-progress
operations and what they mean for starting new operations, but that is
a much harder problem (if it is even possible at all).
Very good points. Thinking aloud, to see if we can start from a few
rules of thumb.
You can be in the middle for two largely different reasons.
One is that the command inherently wants to give control back to
you. Think of a case where you said exec false in the rebase -i
insn sheet, or bisect checked out a version for you to try.
The other is that the command wanted to continue in the ideal world,
but couldn't and stopped asking for your help. Think of a case
where am stopped due to corrupt patch, cherry-pick A..B or
revert stopped due to conflicts.
In the former case, depending on the nature of the command, what are
sensible things you can do are very different (during bisect you
would typically not want to do anything that causes a commit
created. During rebase -i you may want to run any command that
creates a commit, to insert a new one into the series). But a good
rule of thumb would be If I should be able to edit the working tree
file, I should also be able to do cherry-pick --no-commit, merge
--no-commit, apply, etc. If I should be able to manually
commit, I should also be able to cherry-pick, merge, etc.
In the latter, the _only_ reason you are given control back is to
help the interrupted operation. So cherry-pick --no-commit or
apply in lieu of editing files manually in order to fix conflicts
should be allowed, but a random git merge (without --no-commit)
would not be.
So after thinking aloud for a while, I very much agree with you that
you cannot say X is allowed but not Y in many situations.
One thing we can say for sure is that in a middle of a multi-step
operation (e.g. rebase, range pick) is stopped for either one of the
two reasons, you cannot do another multi-step operation. This is
not fundamental but a consequence of how the sequencing machinery is
implemented. But other than that, it really is case-by-case and not
even command-by-command.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
