Hi Junio, On Fri, 13 Oct 2017, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> (The funny "squash!" followed by a complete version of the > >> rewritten commit message is what I do until I -- or anybody else > >> -- comes up with a patch to implement support for "reword!".) > > I have wished for something like that for a long time; it has been > (and it still is) a bit unclear what the semantics and UI should > look like, but still, such a feature would be quite useful. Oh, the reword! semantics are relatively easy in my mind: it would be called as git commit --reword <commit> would take staged changes (if any), otherwise implicitly --allow-empty, then create a commit message to be edited in this style: reword! <original-oneline> <original-oneline> <original-body> This would be presented to the user in an editor (similar to `git commit --amend`). Upon rebase --autosquash, it would work like a squash! but comment out all previous commit messages, and also comment out the reword! line and the empty line after that. In case of multiple reword!, the last one would win, and it would naturally integrate in any fixup!/squash! workflow. What is *more* difficult is something else I frequently need: drop! <oneline>. That is, I want to explicitly mark a commit to be excluded in subsequent rebase --autosquash. I *guess* the best way would be to implement a git revert --drop <commit> that would work as if you called `git revert -n <commit> && git commit -m 'drop! '"$(git show -s --oneline <commit>)", and upon rebase --autosquash, it would reorder like fixup!/squash!/reword!, replace the `pick` of the previous line (if it was a `pick`) by `drop` and comment out the current `pick drop! <oneline>` line. The reason why the semantics are more difficult in that case is that drop! does not mix well with fixup!/squash!/reword!. Ciao, Dscho