Re: [PATCH 3/3] commit: add an option the reword HEAD

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 23, 2020, 10:22 UTC
Message-ID: <nycvar.QRO.7.76.6.2009231206290.5061@tvgsbejvaqbjf.bet>
In-Reply-To: <7f851e7c20aafdae5d5ae46ee1083b32ecc82c84.1600695050.git.gitgitgadget@gmail.com>

Hi Phillip,

On Mon, 21 Sep 2020, Phillip Wood via GitGitGadget wrote:

Show 13 quoted lines

> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> If one notices a typo in the last commit after starting to stage
> changes for the next commit it is useful to be able to reword the last
> commit without changing its contents. Currently the way to do that is
> by specifying --amend --only with no pathspec which is not that
> obvious to new users (so much so that before beb635ca9c ("commit:
> remove 'Clever' message for --only --amend", 2016-12-09) commit
> printed a message to congratulate the user on figuring out how to do
> it). If the last commit is empty one has to pass --allow-empty as well
> even though the contents are not being changed. This commits adds a
> --reword option for commit that rewords the last commit without
> changing its contents.

I would like to explain the idea I tried to get across when I proposed to implement support for `reword!` (and `--reword`) because I feel that it will change the design of this patch in a rather big way.

First of all, let me explain the scenario in which I long for the `--reword` option: I maintain several patch thickets, the most obvious one being Git for Windows' patch thicket that is merge-rebased [*1*] onto every new Git version.

At times, I need to adjust a commit message in that patch thicket. It would be quite wasteful to perform a full merge-rebase, therefore I typically call `git commit --squash <commit> -c <commit>`, copy the oneline, paste it after the `squash!` line (surrounded by empty lines), and then reword the commit message. When the next Git version comes out, I do a merging-rebase, and when the editor pops up because of that `squash!` oneline, I remove the now-obsolete version(s) of the commit message.

Obviously, I have to be careful to either also pass `--only` (which I somehow managed to learn about only today) or I have to make sure that I have no staged changes. In practice, I actually specify a bogus path, which has the same effect as `--only`.

What I would actually rather have is the `--reword` option: `git commit --reword <commit>`. In my mind, this would _add_ a new, "empty" commit, letting me edit the commit message of the specified commit, and using that as commit message, prefixed with the line `reword! <oneline>`.

This, in turn, would need to be accompanied by support in the interactive rebase, to perform the desired reword (which is admittedly quite a bit different from what the way the todo command `reword` works).

With that in mind, I would like to caution against the design of your current patch, because it would slam the door shut on the way I would like `--reword` to work.

Ciao, Dscho

Footnote *1*: In Git for Windows, I want to not only rebase the patches (so that they are as ready to be submitted to the Git mailing list as they can be) but I also want the commit history to fast-forward. The strategy I settled on is the "merging rebase": it is a rebase that starts with a fake merge of the previous commit history, i.e. merging it in using `-s ours` so that only the commit history comes in, but not the changes. This allows contributors to pull without problems, but also provides the benefits of having a rebased version of the patches. The price is a rather big commit history on top of Git's main branch, as Git for Windows' main branch contains not only the newest iteration of its patches, but _all_ iterations (at least since the first merging-rebase).