Resizable message editor & quick reword feature - #2742
d-tatianin wants to merge 2 commits into
Conversation
The editor used for interactive rebase rewords and for the standalone `--rebase-message-editor` mode had a fixed size, which is cramped for longer commit messages. Give it a default size, a minimum size and let the editor stretch to fill the window. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Rewording a single commit currently requires going through the full interactive rebase dialog. Add a `Quick Reword...` item to the commit context menu that opens the commit message editor window and does the rest without further confirmation: - HEAD is amended with `git commit --amend --only`, which leaves staged changes untouched - any other commit reachable from HEAD is reworded via a non-interactive `git rebase -i --autostash`, reusing the existing todo/message editor machinery with a generated job list (pick everything, reword target) After the operation the reworded commit is re-selected in the history view instead of the selection being reset to the top, since the commit keeps the same distance from HEAD. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
|
If you want to reword the HEAD's commit, you can just enable 
|
love-linger
added
not-planned
I know, but this patch is not for rewording the HEAD commit. It's for rewording any commit at or below without entering the full interactive rebase wokflow, give it a try to see the difference. It also preserves the selection offset unlike interactive rebase (which can't really do that because you may e.g. drop or fixup a commit during one) |
I know. I readed your code before. But that's the point I really do not like. In fact, for rewording commits that are not HEAD, you are still performing a rebasing operation, but there is nowhere in your PR for users to know which subsequent commits will also be affected by this operation. |
Subsequent commits shouldn't be affected unless there's a bug in the program, unless you mean that this hides complexity from the user and you don't want that. In this case I think at least commit 1 is useful on its own if you want to take that. |
|
Ah I see, that's an issue. If 2 was fixed, would you take this feature, or is 1 also a blocker in your opinion? (afterall, thats how rebasing in git works) |
This branch has not been deployed
2 participants
No description provided.