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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Aug 4, 2022, 07:57 UTC
Message-ID: <220804.861qtwe8dy.gmgdl@evledraar.gmail.com>
In-Reply-To: <pull.1228.git.git.1659422389830.gitgitgadget@gmail.com>

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

Show 11 quoted lines

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

Show 8 quoted lines

>     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"'