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

From: Brandon McCaig <bamccaig@gmail.com>
Date: Feb 27, 2014, 18:10 UTC
Message-ID: <CANUGeEY2qE2LPq=-bhaKrKrv+uJUaPRqAeW_X1sFyZH-_PRVeA@mail.gmail.com>
In-Reply-To: <20140226105249.GE25711@sigill.intra.peff.net>

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'