rebase -i: quick/inline reword

Currently, `rebase -i` allows modifying the commit titles in the list, and the modified title is shown in the lists of previous and next commands, but the changes are not saved. Currently, modifying just the titles of many commits requires `reword`ing each one and separately and consecutively editing each message, which is annoying when making small, repetitive edits, especially since it requires double-checking each one separately. It would be much easier if there were a mode where any changes to the commit titles in the list modified the commits' titles. Maybe `git rebase -i --reword`?

Any thoughts, suggestions, questions, etc.?

FYI, I am using git version 2.20.1 on `Linux ghostwheel 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux`.

Solomon Ucko

P.S. This is my first time posting here, so let me know if I accidentally violated any rules, e.g. etiquette or formatting.

Solomon Ucko <solly.ucko@gmail.com> writes:

It is probably a bad idea, as it encourages a single-liner commit message without any body.

Equally a bad idea, but perhaps slightly less evil, would be to add a new verb that can be used to replace "pick" with, say, "retitle", and teach the sequencing machinery to pay attention to the updated title line only in that case.

Besides, neither is really workable, as the single line text after the abbreviated commit object name in the todo list is meant as an output only "informational" comment on each step, and there are plans to add more than just the squashed title paragraph there (cf. *1* for an example). Even without such a future change, the material there may not be just the commit title, if I am reading the code correctly, when rebase.instructionFormat is in use.

[Reference]

*1* https://lore.kernel.org/git/pull.757.v3.git.git.1586573067.gitgitgadget@gmail.com/

On Wed, May 06, 2020 at 09:52:19PM -0700, Junio C Hamano wrote:

There is another legitimate use (or at least one I have wished for many times): when manipulating the todo list in my editor to choose patches for editing, I sometimes notice a typo in the title and correct it. And of course that does no good, and I get annoyed. You'd think I would have learned after all these years, but I continue to make the same mistake. ;)

I've often wished that changes there would be quietly persisted. Your "retitle" suggestion would help, but I'd have to remember to use it (I could equally well just remember to use "reword", which I clearly don't).

So I've thought about suggesting this myself in the past, but I held back for the reasons you mentioned below (i.e., that it's not a trustworthy version of the subject in the first place).

I'm not sure if it's solvable or worth solving, but I thought I'd add my 2 cents that the _desire_ at least isn't totally without merit.

-Peff

Jeff King <peff@peff.net> writes:

That's exactly my case as well.

-- Sergey

On Thu, May 7, 2020 at 12:52 AM Junio C Hamano <gitster@pobox.com> wrote:

You could modify the title and keep the rest of the message. You could display the modified message similarly to how `reword` does, to allow modifying the rest of the message.

You could have some sort of separator between the title and the rest of the info. You could disable the extra info when using this mode, if it's a command-line flag. You could require the title to be at the end to use this feature, possibly after some sort of start marker.

Solomon Ucko

Solomon Ucko <solly.ucko@gmail.com> writes:

Yes, thanks for raising the issue!

I've needed the feature many times myself, but then, as Junio already described in his reply, I realized it's likely a no-go with current design of the todo lists. Changing just the titles probably still could be implemented in a useful way (as with your --reword suggestion), but its application is in fact rather limited, so maybe isn't worth the trouble.

It'd be really nice if it were possible to, say, search&replace in, or spell-check, interactively, all the commit messages (including titles) of a bunch of commits to be published, all in a single file handled by single rebase run.

This is a feature that I'd like to see being considered if and when we decide to design a history editing feature that is more powerful than current dos-batch-files-alike processing enhanced with comefrom labels.

-- Sergey

On 2020-05-07 at 10:49:29, Sergey Organov wrote:

It is possible to do this with a bit of shell scripting. You can run "git rebase -x" if you want to check every commit in a certain way.

If instead you'd like to modify all the commit messages, you can use something like this:

  GIT_SEQUENCE_EDITOR="sed -e 's/^pick /reword /'" \
  GIT_EDITOR="some-shell-script-that-modifies-its-file-argument-in-place" \
  git rebase -i BASE

I use something similar as an alias to automatically squash all my squash and fixup commits without needing to open an editor:

  !f() { GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash "$@"; };f

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

These are very good and useful features indeed, and they are examples of batch processing that is very handy for automation, but lacks interactivity. What I rather have in mind is being able to put all the messages /simultaneously/ into my favorite text editor and edit them more or less freely till I'm satisfied, then "commit" the overall result by passing it back to git. Essentially "git rebase -i" on steroids.

-- Sergey

git-revise is a third-party tool that can do this

https://git-revise.readthedocs.io/en/latest/

For example, "git revise -ie" allows you to edit all commit messages in @{u}..HEAD in a single buffer.

Johannes Altmanninger <aclopte@gmail.com> writes:

I only looked at its description but the UI the tool does it with looks quite obvious and intuitive. From its source, the "merge" operation does not seem to handle merging a side branch that renamed files, but that should be OK most of the time, I presume.

Nice.

Junio C Hamano <gitster@pobox.com> writes:

From the docs:

No merge commits may occur between the target commit and HEAD, as rewriting them is not supported.

Yeah, it is!

-- Sergey

Sergey Organov <sorganov@gmail.com> writes:

I didn't read the documentation that deeply, but it's irrelevant that the tool can handle only a single strand of pearls.

You need a merge machinery to implement even a cherry-pick of a single parent commit; an obvious way to implement cherry-pick of commit C on HEAD is to perform three-way merges between C and HEAD, pretending as if C^1 is their sole common ancestor.

Our cherry-pick uses the merge-recursive machinery to do so, and because the sequencer inherited the idea and implementation, "git rebase -i" does the same. They instead use their own written in Python to merge at the tree-level and farms the content-level merge out to "git merge-file".

The "recursive" part of the "merge-recursive" machinery we use does not help cherry-pick at all (as we use only one "common"), but it handles renames. They can do the same in their merge_trees(), but they currently don't.

But as I said, that should be OK most of the time, I would think.

That part is still true ;-)

Johannes Altmanninger <aclopte@gmail.com> writes:

Yeah, exactly what is needed! And there are packages for it both in Debian and Ubuntu, double win! Thanks for sharing!

-- Sergey