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

[Brandon McCaig <bamccaig@gmail.com>]

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. 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 honestly didn't know (or forgot) about the e"x"ec command, but that
to me says that I can automate whatever I want without needing to make
any changes to the rebase --interactive interface. The advantage to
this is that we don't need to reinvent the square wheel that is the
Git command API. We can just exec git ... with the exact same command
set and options that we're already familiar with. No doubts about
syntax or disparities, etc.

I don't think it's my place to resist these changes; particularly
because I don't think they'd necessarily affect me, except for maybe
the proposed automatic merge support, but if that SOMEHOW actually
works reliably and sensibly (i.e., to allow you to rebase over merges
without losing the merges) I'm not sure I'd complain. That said, I do
think that this is probably a bad direction and shouldn't be rushed
into too fast. It seems like it would be a complicated thing to do,
more complicated to do well, and I'm not sure that it would really
improve things any. I'm not sure that users would prefer to use this
over "e"diting and/or e"x"ecing instead. Plus where do you draw the
line as far as which features to reproduce? How do you prevent scope
creep?

> [1] The one feature I would like in this vein is that editing the title
>     in the instruction-sheet would modify the commit message of the
>     relevant commit. For some reason I try to do this every few weeks,
>     but of course the changes are just thrown away.

When I do this I am usually half asleep and it's a good reminder to
pay attention to what I'm doing. I'd probably rather Git *error* when
I change the subject line and tell me why it doesn't make sense and
recommend "r"eword instead.

Regards,


-- 
Brandon McCaig <bamccaig@gmail.com> <bamccaig@castopulence.org>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bamccaig.com/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'