Hi Paul, On Wed, 16 Mar 2016, Paul Tan wrote: > On Wed, Mar 16, 2016 at 4:04 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > In addition I want to point out that sequencer's replay_opts seem to be at > > least related, but the patch shares none of its code with the sequencer. > > Let's avoid that. > > > > In other words, let's try to add as little code as possible when we can > > enhance existing code. > > Well, both git-rebase--am.sh and git-rebase--merge.sh do not use the > sequencer functionality at all, and we don't see git-am for example > needing to be aware of onto, orig-head, head-name etc. That is arguing that the implementation of --am and --merge is too far away from the sequencer and therefore should not be made closer. By that token, has_unstaged_changes() should never be allowed to call init_revisions(): it *never* looks at any revisions at all! And the idea of the sequencer is so much more related to --am and --merge than unstaged changes are to revisions: the entire purpose of the sequencer (no matter the *current* implementation with all its limitations) is to apply a bunch of patches, in sequence. That is pretty much precisely what *all* members of the rebase family are about. In other words: please do not let current limitations dictate that we should introduce diverging code for essentially the same workflow. Ciao, Dscho -- 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