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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 28, 2014, 14:03 UTC
Message-ID: <53109748.3090507@alum.mit.edu>
In-Reply-To: <20140228125241.GA23448@sigill.intra.peff.net>

On 02/28/2014 01:52 PM, Jeff King wrote:

Show 36 quoted lines

> [...]
> Sorry, I missed an important word in my final sentence. It should have
> been "the examples you gave are NOT particularly interesting to me".
> 
> On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:
>> 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.

I guess I misread the sentiment of the mailing list, because I merged this idea into the list about two hours ago.

I'm not claiming that all of the sub-ideas are good, but I do think that some of them are, and that the general idea of allowing options on todo-list commands would make it possible for them to be more expressive while *avoiding* making them a lot harder to learn. I would rather give the user a few options that can be used consistently on multiple commands than have to invent a new command for each new feature. And I think that the line-oriented nature of the todo list makes

    pick --signoff 1234abc Blah blah

easier to understand (and easier to type) than

    pick 1234abc Blah blah
    amend --signoff

let alone

    pick 1234abc Blah blah
    exec git commit --amend --signoff

I also like the idea of a non-broken "git rebase --interactive --preserve-merges" via a todo option "-p" or something similar.

But if you think that even the proposal's simpler sub-ideas are controversial, then let me know and I will delete the idea from the list again. I don't want a GSoC student to have to fight battles of my own creation :-)

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/