git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* rebase -i: quick/inline reword
@ 2020-05-07  4:27 Solomon Ucko
  2020-05-07  4:52 ` Junio C Hamano
  2020-05-07 10:49 ` Sergey Organov
  0 siblings, 2 replies; 13+ messages in thread
From: Solomon Ucko @ 2020-05-07  4:27 UTC (permalink / raw)
  To: git

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-07  4:27 rebase -i: quick/inline reword Solomon Ucko
@ 2020-05-07  4:52 ` Junio C Hamano
  2020-05-07 11:46   ` Jeff King
  2020-05-07 14:01   ` Solomon Ucko
  2020-05-07 10:49 ` Sergey Organov
  1 sibling, 2 replies; 13+ messages in thread
From: Junio C Hamano @ 2020-05-07  4:52 UTC (permalink / raw)
  To: Solomon Ucko; +Cc: git

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/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-07  4:27 rebase -i: quick/inline reword Solomon Ucko
  2020-05-07  4:52 ` Junio C Hamano
@ 2020-05-07 10:49 ` Sergey Organov
  2020-05-08  0:05   ` brian m. carlson
  1 sibling, 1 reply; 13+ messages in thread
From: Sergey Organov @ 2020-05-07 10:49 UTC (permalink / raw)
  To: Solomon Ucko; +Cc: git

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-07  4:52 ` Junio C Hamano
@ 2020-05-07 11:46   ` Jeff King
  2020-05-07 12:17     ` Sergey Organov
  2020-05-07 14:01   ` Solomon Ucko
  1 sibling, 1 reply; 13+ messages in thread
From: Jeff King @ 2020-05-07 11:46 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Solomon Ucko, git

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-07 11:46   ` Jeff King
@ 2020-05-07 12:17     ` Sergey Organov
  0 siblings, 0 replies; 13+ messages in thread
From: Sergey Organov @ 2020-05-07 12:17 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, Solomon Ucko, git

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-07  4:52 ` Junio C Hamano
  2020-05-07 11:46   ` Jeff King
@ 2020-05-07 14:01   ` Solomon Ucko
  1 sibling, 0 replies; 13+ messages in thread
From: Solomon Ucko @ 2020-05-07 14:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-07 10:49 ` Sergey Organov
@ 2020-05-08  0:05   ` brian m. carlson
  2020-05-08 21:14     ` Sergey Organov
  0 siblings, 1 reply; 13+ messages in thread
From: brian m. carlson @ 2020-05-08  0:05 UTC (permalink / raw)
  To: Sergey Organov; +Cc: Solomon Ucko, git

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-08  0:05   ` brian m. carlson
@ 2020-05-08 21:14     ` Sergey Organov
  2020-08-16  0:14       ` Johannes Altmanninger
  0 siblings, 1 reply; 13+ messages in thread
From: Sergey Organov @ 2020-05-08 21:14 UTC (permalink / raw)
  To: brian m. carlson; +Cc: Solomon Ucko, git

"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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-05-08 21:14     ` Sergey Organov
@ 2020-08-16  0:14       ` Johannes Altmanninger
  2020-08-16  5:36         ` Junio C Hamano
  2020-08-16 12:21         ` Sergey Organov
  0 siblings, 2 replies; 13+ messages in thread
From: Johannes Altmanninger @ 2020-08-16  0:14 UTC (permalink / raw)
  To: sorganov; +Cc: git, sandals, solly.ucko

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-08-16  0:14       ` Johannes Altmanninger
@ 2020-08-16  5:36         ` Junio C Hamano
  2020-08-16 12:24           ` Sergey Organov
  2020-08-16 12:21         ` Sergey Organov
  1 sibling, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2020-08-16  5:36 UTC (permalink / raw)
  To: Johannes Altmanninger; +Cc: sorganov, git, sandals, solly.ucko

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-08-16  0:14       ` Johannes Altmanninger
  2020-08-16  5:36         ` Junio C Hamano
@ 2020-08-16 12:21         ` Sergey Organov
  1 sibling, 0 replies; 13+ messages in thread
From: Sergey Organov @ 2020-08-16 12:21 UTC (permalink / raw)
  To: Johannes Altmanninger; +Cc: git, sandals, solly.ucko

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-08-16  5:36         ` Junio C Hamano
@ 2020-08-16 12:24           ` Sergey Organov
  2020-08-16 16:55             ` Junio C Hamano
  0 siblings, 1 reply; 13+ messages in thread
From: Sergey Organov @ 2020-08-16 12:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Altmanninger, git, sandals, solly.ucko

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebase -i: quick/inline reword
  2020-08-16 12:24           ` Sergey Organov
@ 2020-08-16 16:55             ` Junio C Hamano
  0 siblings, 0 replies; 13+ messages in thread
From: Junio C Hamano @ 2020-08-16 16:55 UTC (permalink / raw)
  To: Sergey Organov; +Cc: Johannes Altmanninger, git, sandals, solly.ucko

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 ;-)

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-08-16 16:56 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-07  4:27 rebase -i: quick/inline reword Solomon Ucko
2020-05-07  4:52 ` Junio C Hamano
2020-05-07 11:46   ` Jeff King
2020-05-07 12:17     ` Sergey Organov
2020-05-07 14:01   ` Solomon Ucko
2020-05-07 10:49 ` Sergey Organov
2020-05-08  0:05   ` brian m. carlson
2020-05-08 21:14     ` Sergey Organov
2020-08-16  0:14       ` Johannes Altmanninger
2020-08-16  5:36         ` Junio C Hamano
2020-08-16 12:24           ` Sergey Organov
2020-08-16 16:55             ` Junio C Hamano
2020-08-16 12:21         ` Sergey Organov

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git