Jonathan Nieder wrote: > Well, let's start here. The two insns "pick" and "revert" and the > ability to mix them doesn't have much to do with the picture, does it? > > I think the actual problem being solved is that insn types, as described > by the replay_action enum, are being abused to refer to top-level git > commands "revert" and "cherry-pick". The sequencer isn't supposed to > care which top-level git command called it, except in some messages, so > we'd certainly like to stop pretending that has something to do with > insn types. Exactly. I'll update the commit message. > Based on what you've said, correcting this cleanly is complicated in > some places by the inconvenient fact that the sequencer _does_ care > which top-level git command called it. (I haven't checked this; I'm > just taking it on faith from you.) If we want to let other git > commands (like "git rebase" or "git sequence") call into the > sequencer, that sounds like a way bigger problem than any conflict of > terminology. There's no need to trust me: just think about the problem. We fill out a replay_opts structure to call into the sequencer with- how does the sequencer know what to do with this hypothetical command string (say "cherry-pick") on a fresh invocation? It needs to translate this into a replay_action at some point, right? There are atleast three places where this happens: prepare_revs(), walk_revs_populate_todo(), and single_pick(). -- Ram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html