Hi Dscho On 23/09/2020 11:22, Johannes Schindelin wrote:
Hi Phillip, On Mon, 21 Sep 2020, Phillip Wood via GitGitGadget wrote:From: Phillip Wood <phillip.wood@xxxxxxxxxxxxx> 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.
I'm keen to have an easy way to reword HEAD and a way to implement your reword! idea.
I posted a comment on your gitgitgadget issue about reword! and drop![1] pointing to some patches[2] that implement the reword! idea as amend!. I think we want to be able to fixup a commit and reword it at the same time which is way I chose the name amend! rather than reword! The implementation currently changes `git commit --amend` to take an optional commit which isn't ideal. I wonder if calling it revise! would be better then we could have `git commit --reword` to reword HEAD and `git commit --revise <commit>` to create a commit that will reword and fixup <commit> when the user runs `git rebase -i --autostash`. fold! is another possibility.
I don't think this patch series stops us implementing something for rebase but it would mean we couldn't use the name reword! unless we allow `git commit --reword` to take an optional commit which I'm not that keen on.
What do you think to an alternative name? Best Wishes Phillip [1] https://github.com/gitgitgadget/git/issues/259 [2] https://github.com/phillipwood/git/commits/wip/rebase-amend
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).
