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

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
[off-list ref] wrote:

On Wed, 16 Mar 2016, Paul Tan wrote:

quoted

On Wed, Mar 16, 2016 at 4:04 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

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