Implement a git reword command

[bcongdon]

As discussed in #48.

[arxanas]

git-revise supports bulk commit message editing, which I think is a good feature. If you reword multiple commits at once, then it opens an editor with all of their commit messages separated by some marker. That way, you can use your editor's facilities to apply bulk edits (e.g. find and replace). Assuming that the syntax is git reword [<commit>], it would be good to support once the argument can accept a revset (#175) and therefore refer to multiple commits.

[epage]

So I've not used git-revise but this sounds cool! Its not just bulk edits but a smoother experience instead of dropping in and out of the editor. This also provides a path for a nice default of git reword (no args) just re-wording HEAD and everything before it and people just jump to what they want rather than spending the time specifically selecting.

Does it show give context for those commits? I'm wondering about the idea of having markers with commented out commit messages for the ones not being edited so people can doesn't have to keep relevant state in mind but can refer back to the other commits.

[arxanas]

It looks like the bulk commit editing is actually part of a feature to do commit editing inline with the rebase plan. You can get this view if you use git revise -ie <target>:

++ pick 641b83415297
fix(rewrite): check out the correct branch upon `git rebase --abort`

++ pick f1ac4a494d86
fix(rewrite): don't write symbolic reference to `ORIG_HEAD`

Git expects `ORIG_HEAD` to be a direct reference. In some cases, commands will write to `ORIG_HEAD` in an attempt to back something up, but dereference the symbolic reference first, which actually causes random references to be overwritten.


# Interactive Revise Todos(2 commands)
#
# Commands:
#  p, pick <commit> = use commit
#  r, reword <commit> = use commit, but edit the commit message
#  s, squash <commit> = use commit, but meld into previous commit
#  f, fixup <commit> = like squash, but discard this commit's message
#  c, cut <commit> = interactively split commit into two smaller commits
#  i, index <commit> = leave commit changes staged, but uncommitted
#
# Each command block is prefixed by a '++' marker, followed by the command to
# run, the commit hash and after a newline the complete commit message until
# the next '++' marker or the end of the file.
#
# Commit messages will be reworded to match the provided message before the
# command is performed.
#
# These blocks are executed from top to bottom. They can be re-ordered and
# their commands can be changed, however the number of blocks must remain
# identical. If present, index blocks must be at the bottom of the list,
# i.e. they can not be followed by non-index blocks.
#
#
# If you remove everything, the revising process will be aborted.

We might want to use more or less context than this.

[epage]

I'm curious, do you expect git reword to be tied to git branchless init or would it be like #183? I'd like

• git revise -ie like behavior
• Branches to be preserved
• Able to be used independent of git branchless.

Trying to decide if its worth making my own or if I can somehow install yours without the other parts (or just not run the other parts)

[arxanas]

I think it would be reasonable to make git reword work without git branchless init/hooks.

[bcongdon]

If you reword multiple commits at once, then it opens an editor with all of their commit messages separated by some marker.

That sounds like a useful feature. 👍 I was thinking that even in the single-commit case, there should be support for dropping into the $EDITOR. e.g. git reword -m "new message" is legal, but the bare git reword would drop you into the commit message editor similar to git commit --amend. Maybe the single-commit case is just a special case of multi-commit reword.

[arxanas]

I wonder what the behavior should be for git reword -m "new message" 'revset_expr_returning_multiple_commits()'?

For the future implementor, dialoguer has a function to spawn an editor, which might be useful:https://docs.rs/dialoguer/0.9.0/dialoguer/struct.Editor.html

[claytonrcarter]

Perhaps something like:

• git reword - open $EDITOR, amend HEAD
• git reword <commit> - open $EDITOR, amend <commit>
• git reword <multiple commits> - open $EDITOR for bulk editing of <multiple commits>
• git reword -m <message> - use <message> to amend HEAD
• git reword <commit> -m <message> - use <message> to amend <commit>
• git reword <multiple commits> -m <message> - use same <message> to amend all <multiple commits>, possibly printing a warning to stderr or something like that

Personally, I could see myself using all of these. The last is the oddest, of course, but could be useful for something like git reword <buncha commits on branch> -m 'fixup!' && git rebase -i --autosquash main

[claytonrcarter]

For those playing along at home, git reword was recently merged into master via #304. To the best of my knowledge, it handles everything discussed here except bulk edit mode a la git revise -ie. I would love hear your thoughts and experiences from using it in it's present form.

Bulk edit mode is next up, but I'm going to try really hard to take a short break before digging into it. If you have any ideas or suggestions for that feature, please share them. FWIW, my current plan is to stick close to the format used by git revise -ie so that folks that use both will feel comfortable switching back and forth, and to avoid any unnecessary wheel reinvention. Something like this:

++ reword abc123
This is the commit message for abc123.

++ reword def456
This is the commit message for def456.

# Rewording 2 commits. 
# ... some helpful, descriptive message here ...

[arxanas]

Since we have support for a fairly functional git reword command, I'm going to close this issue. We can discuss further improvements/features in Discussions or on Discord. @claytonrcarter thanks again 😄