Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> The problem is that the `git-rebase-todo` most definitely does *not* want
> to be restricted to a single command.
Looking at the test in question, it is about what happens when "git
cherry-pick A..B" runs, and the test assumes it gets a sequence of
"pick". It would be a bug to see any "revert" in there if you are
doing a multi cherry-pick.
And what is checked is if "cherry-pick --continue" notices a
malformed instruction that has something other than "pick".
If the final invocation were "sequencer --continue", then I
perfectly well understand why it is not a good idea to limit the set
of instructions only to "pick" (or "revert"). But I do not think
the test performed here is for that general case. The user knows
Git stopped in the middle of cherry-pick and expects cherry-pick to
> So if you must have a patch that disagrees with this overzealous check,
> the "revamp todo parsing" one is probably the first. But it is better to
> think of this at a higher level than just patches: it is wrong to limit
> the todo script to contain only identical commands.
So if you think of this at even higher level, the check done in
parse_insn_line() that _assumes_ that opts->action must match the
actions on each line is _WRONG_, but what this test expects to see
is perfectly reasonable, I would think.
It is a different matter if it makes sense to _verify_ that the user
didn't make nonsensical change to the generated insn and error out
when s/he did. I tend to think it is pointless, and I wouldn't object
if this test is removed due to that reason.