Re: [PATCH] rebase: introduce allow-inline-reword option

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Aug 02 2022, Théo MAILLART via GitGitGadget wrote:

> From: =?UTF-8?q?Th=C3=A9o=20Maillart?= <tmaillart@gmail.com>
>
> This new option (false by default) for interactive rebase allows users
> to modify the subject of a commit directly in the todo list, when they
> select the "reword" action.
> If the option is enabled, "reword" is selected and the subject has not
> changed, then the default behaviour is used.
> It also introduces a test for this specific option, and a related
> function (set_inline_reword_editor) in the lib-rebase.sh to use a
> simpler custom fake editor to be able to modify the message part of the
> lines in a todo list (in the most simple cases).

I won't repeat what others have noted (e.g. reference to earlier
discussions).

Just an observation: When I use "git rebase -i" I use Emacs's
"git-rebase-mode.el" to view the resulting buffer, it has useful
shortcuts. E.g. M-p and M-n move a line up/down, "c" is pick", "r" is
reword etc.

Now that mode can mark the whole buffer read-only, there is a way to
insert into it, e.g. with "y" to insert a <rev>, or "x" to insert
"exec", but those bring up an interactive dialog.

But there's nothing that e.g. would warrant search/replacing the whole
buffer now.

It's no big deal for an Emacs mode to add it I'd think, just worth
considering what we're pushing to downstream UX's.

>     If the user only wants to modify the subject of a commit during
>     interactive rebase, now he can choose the "reword" command and change
>     the subject directly in the todo list. If "reword" is selected and the
>     subject has not changed, then we use the default behavior. Here is a
>     demo https://asciinema.org/a/T9tEmUjjl4dyDuaXalPzXNzo1
>     
>     This is probably not the correct way to implement this new feature, or
>     perhaps it is not desirable, so I would like some feedback. Thank you

Wouldn't another implementation of this be to do:

	exec EDITOR="..." git commit --amend

Where that "editor" is a sed one-liner to s/<first line>/replacement/?

I don't mind this feature per-se, but I will observe that since I
started using git-rebase-mode.el its keymap has gotten much more
cluttered over the years, as we've added more special modes (and it has
maps of its own).

I don't object to it, but wonder if we couldn't add something that's
more generic, and wouldn't require e.g. a
--allow-adding-a-new-paragraph-after-the-subject-that-is-already-there,
i.e. some users will want to reword the subject, others want to add a
signed-off-by.

For the SOB case we already have:

	git rebase -i -x 'git commit --no-edit --amend -s'

Perhaps we could/should have instead:

	git commit --amend-subject

Which would allow you to do:

	git rebase -i -x 'git commit --amend-subject -m"new subject here, does not touch anything past the first \n\n"'