rebase -i: quick/inline reword

rebase -i: quick/inline reword

[Solomon Ucko]

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.

Re: rebase -i: quick/inline reword

[Junio C Hamano]

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

> ... 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.?

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/

Re: rebase -i: quick/inline reword

[Sergey Organov]

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

> 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.?

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

Re: rebase -i: quick/inline reword

[Jeff King]

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

> Solomon Ucko <solly.ucko@gmail.com> writes:
> 
> > ... 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.?
> 
> It is probably a bad idea, as it encourages a single-liner commit
> message without any body.

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

Re: rebase -i: quick/inline reword

[Sergey Organov]

Jeff King <peff@peff.net> writes:

> On Wed, May 06, 2020 at 09:52:19PM -0700, Junio C Hamano wrote:
>
>> Solomon Ucko <solly.ucko@gmail.com> writes:
>> 
>> > ... 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.?
>> 
>> It is probably a bad idea, as it encourages a single-liner commit
>> message without any body.
>
> 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.

That's exactly my case as well.

-- Sergey

Re: rebase -i: quick/inline reword

[Solomon Ucko]

On Thu, May 7, 2020 at 12:52 AM Junio C Hamano <gitster@pobox.com> wrote:
> It is probably a bad idea, as it encourages a single-liner commit
> message without any body.

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.

> 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.

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

Re: rebase -i: quick/inline reword

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On 2020-05-07 at 10:49:29, Sergey Organov wrote:
> 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.

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: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: rebase -i: quick/inline reword

[Sergey Organov]

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

> On 2020-05-07 at 10:49:29, Sergey Organov wrote:
>> 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.
>
> 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

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

Re: rebase -i: quick/inline reword

[Johannes Altmanninger]

> >   !f() { GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash "$@"; };f
> 
> 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.

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.

Re: rebase -i: quick/inline reword

[Junio C Hamano]

Johannes Altmanninger <aclopte@gmail.com> writes:

>> >   !f() { GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash "$@"; };f
>> 
>> 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.
>
> 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.

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.

Re: rebase -i: quick/inline reword

[Sergey Organov]

Johannes Altmanninger <aclopte@gmail.com> writes:

>> >   !f() { GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash "$@"; };f
>> 
>> 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.
>
> 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.

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

-- Sergey

Re: rebase -i: quick/inline reword

[Sergey Organov]

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

> Johannes Altmanninger <aclopte@gmail.com> writes:
>
>>> >   !f() { GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash "$@"; };f
>>> 
>>> 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.
>>
>> 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.
>
> 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.

From the docs:

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

>
> Nice.

Yeah, it is!

-- Sergey

Re: rebase -i: quick/inline reword

[Junio C Hamano]

Sergey Organov <sorganov@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.
>
> From the docs:
>
> No merge commits may occur between the target commit and HEAD, as
> rewriting them is not supported. 

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.

>> Nice.
>
> Yeah, it is!

That part is still true ;-)