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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 27, 2014, 07:48 UTC
Message-ID: <530EEDBA.6090804@alum.mit.edu>
In-Reply-To: <20140226105249.GE25711@sigill.intra.peff.net>

On 02/26/2014 11:52 AM, Jeff King wrote:

Show 13 quoted lines

> On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote:
> 
>> It would be nice to support more flexibility in the todo-list commands
>> by allowing the commands to take options.  Maybe
>>
>> * Convert a commit into a merge commit:
>>
>>       pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after
> 
> 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]).

Don't forget that any of the parent commits might have been rewritten due to the earlier lines of the rebase script. Rebase has to map the specified SHA-1s to their new versions. So I don't think that this one would be very practical to implement by hand.

Actually I think it is awkward to have to specify all of the parent commits. I did it this way to make it look like commit-tree's -p option. But any usage of this feature that *doesn't* include the immediately preceding commit as a parent would probably be broken anyway (for example, the preceding commit would become unreachable).

So maybe a better UI would be

    pick --merge=e1ee712 deadbab The oneline of the commit after

(even though this precludes the short form "-m" because it is already taken by --message).

On the other hand, allowing arbitrary parents with "-p" might be a way to make "rebase --interactive" work half-sanely with parts of history that *already* include merge commits. The todo list that rebase prepares for the user would already include these "-p" lines.

What I like about allowing options in todo lists is that is that it opens up a lot of possibilities for "git rebase --interactive" that, I think, have previously been hampered by the restriction that commands have to consist of a single word, and (until now) have to be abbreviable to a single distinct letter.

Michael

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