idea: Support rewording summaries directly in the -i view

[anordal]

I know from past git rebase -i usage that I sometimes instinctively try to edit commit summary lines directly in the interactive line view, instead of selecting to reword each messaage. Which just drops my changes. And despite learning this lesson numerous times, it still happens that I forget myself.

Learning that the awesome git revise -ie command supports bulk renaming, I had to see what it would do in -i mode, and the story seems to be the same. Thus what the headline suggests.

Benefits:

1. It is nice when it just works™.
2. Avoids a separate renaming pass if you already are in -i mode for other reasons.
3. Not all editors have a block mode that supports editing multiple non-consecutive lines (making the -ie view less ideal when you only want to edit the first line of each commit).

[mystor]

I considered allowing rewording of the summary line in the base interactive view, but was worried it might be surprising for the changes there to be reflected in actual commits. It might be worth supporting this, but keeping a git config (maybe revise.editSummaries?) to turn the behaviour off?

[Manishearth]

I'd love this with a config, but without a config the behavior would be a surprising departure from what rebase does IMO.

[anordal]

I can't think of a case where the user makes a change, saves, exits, and expects the change to be discarded, but I can think of cases where an editor might mispreserve text. Like unicode normalization, illegal byte sequences, non-printable characters, or line ending conventions.

Assuming that most users won't encounter these problems in their immediate git history, a config option might actually make sense. That said, the need for configurability is often a sign of a bad idea (see fish design doc: Configurability is the root of all evil).

A compromise might be a sort of inline-reword command, that does the same, just makes the intent explicit.

[Manishearth]

I can't think of a case where the user makes a change, saves, exits, and expects the change to be discarded

The reason the git rebase syntax works this way is that you should be able to just deal with commit hashes, revise does the same thing. The commit messages are basically comments, there to help you, but not consumed by the tool. It's hard to tell the intent behind a "change", the user might have typed in an extra commit to be cherry picked, and that shouldn't automatically mean its message is set to the empty string.

inline-reword does sound like a nice idea, but it does feel verbose.

[emilazy]

+1 for a command for this; maybe reword! (r! for short) to capture the "don't prompt me for more about this afterwards" intent, and reword can default to using the modified subject line for the new commit?

[parkercoates]

This feature would introduce some ambiguity about what would happen to the body of the commit message when editing the summary in the interactive revise window. Is the body removed or kept? It's not obvious to me which behaviour is most useful and/or least surprising.

If I happened to be running an interactive revise and noticed a typo in a message summary, I would be quite surprised if fixing that typo wiped out the message body. Conversely, if I completely rewrote the message summary while doing an interactive revise, I might be surprised if the old message body stuck around.

Personally, I'd be much more interested in some kind of --bulk-reword functionality that was completely separate from the --interactive mechanism. Something that put all of the commit messages, in their entirety, into a single editor window.

#######################################################################
### Commit #1: 123abc456def
This is the summary of the first commit message

This is the body of the first commit message, which is very, very, very long
and contains multiple lines.

#######################################################################
### Commit #2: 234bcd567efa
This is the summary of the second commit message, which has no body

#######################################################################
### Commit #3: 345cde678fab
Yet another commit

That has a real cool message body, as well as some trailing metadata lines

Issue: BUG-1234
Approved by: Joe Developer

[Manishearth]

git revise -ie does exactly what you're talking about with --bulk-reword

[anordal]

To be precise, I only meant for the summary line to be affected, since there is git revise -ie for the full thing.

[elonderin]

while this has happened to me too in that past, i wouldnt do this.
just have an alias to always do -ie if you need it always.

Another simple option is to stick it in you face that the messages are just here as read-only/info purpose by putting a comment block that says so.

[anordal]

Argh, I haven't stopped fooling myself. It's too intuitive.

stick it in you face that the messages are just for info by putting a comment block that says so

I'm not hopeful. This is a routine task – I wouldn't notice if the comments changed ever so much, because I'm laser focused on those commit summaries. My brain sees text, changes it, saves, force pushes my feature branch and goes home for the weekend. Then, I remember that it doesn't work.

[anordal]

I have something here:
https://github.com/anordal/git-revise/commits/rebasehappy-integration-tryout

(That's a branch for adding together PRs and other unreleased work in progress)

[krobelus]

I think git rebase doesn't support this because it would encourage bad practice of neglecting the commit message body.
Also it has the potential to break GIT_SEQUENCE_EDITOR scripts that don't provide the subject. Though those are more likely to be used with git-rebase, not with git-revise. Maybe it's fine as an optional thing but I've gotten used to it.