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

[Jeff King <peff@peff.net>]

On Wed, Feb 26, 2014 at 12:14:11PM +0100, Michael Haggerty wrote:

> > [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.
> 
> Given that commit messages can be more than one line long, a feature
> like this would be confusing, I think, and perhaps subtly encourage
> people to limit their commit messages to a single line, which would be a
> bad thing.

Right, I was assuming it would just modify the subject-line, and leave
the rest intact (I often want to use it to just replace one word or fix
a typo, since I am starting right at it in the insn sheet).

> Plus, until now such edits were thrown away, so there are
> backwards compatibility problems if we suddenly start preserving such edits.

Good point. For true interactive use it probably wouldn't be that big a
deal, but people do weird things with GIT_EDITOR and auto-munging the
list of commits. A heuristic like "is there any message there at all"
might work, as you mentioned, but heuristics make me nervous.

> But using the other ideas discussed here one could do
> 
>     pick -m "New log message" <sha1>

Yeah, that would work, though you have to retype the whole thing, which
is potentially annoying (clever use of your editor can pull it over from
the other side, but it's not super-friendly).

Something like:

  pick --subject <sha1> <modified message...>

would be simpler.

>     amend -m "Revised log message"

That would replace the whole message, which I definitely don't want (and
would encourage bad habits).

> Another, more wonkish idea I though of would be
> 
>     pick --tree=<treeish> <sha1>
> 
> to force the tree of the commit to be set to that of the specified
> <treeish> while keeping the commit metadata from <sha1>.

I think there's a large foot-shooting capacity there. Any commit you've
reordered from after the "--tree" to before it will mysteriously get
undone in the "--tree" commit. E.g.:

  pick aaaaaaa
  pick bbbbbbb
  pick ccccccc

being done as:

  pick ccccccc
  pick bbbbbbb
  pick --tree=bbbbbbb aaaaaaa

-Peff