Hi Dscho, (Sorry for the very late reply, I got caught up with some unexpected work and am still clearing my inbox ><)
On Thu, Mar 17, 2016 at 1:11 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > On Wed, 16 Mar 2016, Paul Tan wrote: >> On Wed, Mar 16, 2016 at 4:04 PM, Johannes Schindelin >> <johannes.schinde...@gmx.de> 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. Ah, so you are thinking of replacing the --am and --merge scripts with sequencer? That sounds great :-) I'll wait for your sequencer patch series then. Thanks! Paul -- 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
