Re: GSoC idea: allow "git rebase --interactive" todo lines to take options

[Jeff King <peff@peff.net>]

On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:

> On Wed, Feb 26, 2014 at 5:52 AM, Jeff King <peff@peff.net> wrote:
> > This seems like a reasonable feature to me. All of your examples are
> > possible with an "e"dit and another git command, but the convenience may
> > be worth it (though personally, most of the examples you gave are
> > particularly interesting to me[1]).
> 
> This strikes me as over-complicating the rebase --interactive
> interface.

Sorry, I missed an important word in my final sentence. It should have
been "the examples you gave are NOT particularly interesting to me".

> Particularly all of the ideas expressed later on about
> merge commits and resetting authors, etc. It seems like you're trying
> to define a whole new command set (i.e., API) for Git, but within the
> context of rebase --interactive. I think it would be hard to document
> this, and hard to learn it, and harder still to remember it (even
> though it would obviously try to mirror the existing Git command API).

I agree some of the examples are getting esoteric. Things like --signoff
and --reset-author are a fairly straightforward convenience feature:
they save you from writing "exec git commit --amend --signoff".

For others that cannot currently be done with a simple option to "git
commit", I think a reasonable first step would be to implement them
there. For example, you cannot currently "git commit --tree". Maybe that
is too insane and low-level an option for "git commit". But if it is,
then it is almost certainly too insane and low-level for a rebase
instruction.

For others from Michael's list, I expect they may not make _sense_
outside of a rebase. That is, they are operations whose input is not a
single commit, but a sequence of commits (e.g., if you had some
high-level command that allowed swapping two commits without having to
redo the conflicts from the second commit). Those ones might make sense
to exist as part of rebase and nowhere else (but then they are not
necessarily just options, but rather new instructions).

> That said, I do think that this is probably a bad direction and
> shouldn't be rushed into too fast.

I'm not sure whether it is a good idea or not. But I think it is looking
decreasingly like a good GSoC project.

-Peff