Re: [PATCH/RFC/GSoC 05/17] rebase-options: implement rebase_options_load() and rebase_options_save()

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 16, 2016, 17:11 UTC
Message-ID: <alpine.DEB.2.20.1603161802080.4690@virtualbox>
In-Reply-To: <CACRoPnS4JpNNACz4T0F0vFs3ogG+nzk-y1=zc1UrtAZKaEnggg@mail.gmail.com>

Hi Paul,

On Wed, 16 Mar 2016, Paul Tan wrote:

Show 12 quoted lines

> On Wed, Mar 16, 2016 at 4:04 PM, Johannes Schindelin
> <Johannes.Schindelin@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.

Ciao, Dscho