I think that you should think carefully if there would be no troubles
with this way of specifying options. Perhaps explicit file option
(-F/--file=<file>), or optional '--' separating revisions. But
perhaps my fears are for nothing, and current proposal is good
solution.
The common '--continue | --skip | --abort' infrastructure is, I think,
one of the most important things about this. I'd like to have
'--what' (or '--status') option to tell us if we are in the middle of
sequence of oprations, and what this sequence is (rebase, rebase -i,
am, revert, cherry-pick, sequencer <file>,...).
Two comments (as I don't use "git rebase -i", preferring to work with
StGIT, Quilt-like patch management interface).
First, if git-sequencer is to become backbone for cherry-pick,
allowing for example long requested cherry-picking multiple commits
(squasing them or not into single commit), is should be able to use it
also for git-revert. Thus I'd like to have either "pick -R" or
"revert" command.
Second, about "pick" accepring (I guess) git-cherry-pick options: I
would like to have documentation on '--mainline <parent-number>'
option in git-sequencer manpage, or at lest explicitely mentioned that
it can be used to pick merge commits. BTW, is "pick --no-commit"
symmetric equivalent^W alternative to "squash"?
--
Jakub Narebski
Poland
ShadeHawk on #git
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html