Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Michael J Gruber <hidden>
Date: 2016-06-15 22:47:49
Michael Haggerty venit, vidit, dixit 04.12.2009 15:36:
This patch series adds "fix" to the commands that can be used within
the "rebase --interactive" patch editor. "fix" is like "squash"
except that it discards the log message of the corresponding commit.
Why I would like this feature:
One of my favorite aliases is
fix = commit --amend -C HEAD
which I use in those all-too-frequent head-slapping "I just committed
something with a minor typo" moments. It amends the last commit with
whatever is staged, reusing the same commit message. It can also be
used with the "-a" option, a list of filenames, etc.
But sometimes I don't have my head-slapping moments until a few
commits later. In this case, my usual practice is to commit the
trivial typo change on top of the current branch, then "rebase
--interactive" to move the typo fix on top of the erroneous commit and
squash it:
pick 05d3b81 Commit with typo
pick c29114a Good commit 1
pick 250b013 Good commit 2
pick 5eb3299 Fix for typo
|
V
pick 05d3b81 Commit with typo
squash 5eb3299 Fix for typo
pick c29114a Good commit 1
pick 250b013 Good commit 2
But then it is necessary to go into the commit message editor, move
the cursor down past the first commit message, delete the "Fix for
typo" commit message, save, and quit.
This patch implements a "fix" command, similar to "squash", except
that the corresponding log message is not included in the log message
suggested for the combined commit. (In fact, it includes the log
message, but commented out.) It therefore saves the editor chores.
"fix" and "squash" can be used in the same group, in which case the
"squash" commit messages are preserved and the "fix" commit messages
are skipped.
If the idea of a "fix" command is acceptable, then I would like to
implement a further convenience: if a group of commits to be folded
together includes *only* "fix" commits, then the first log message
should be used without even opening an editor. But I would like to
get a reaction to the "fix" command in general before doing so.
I'd say that would make a useful command ("fix") even more useful, being
just the right counterpart to "reword" for trivial commit message fixes.
OTOH, it would not be possible any more to squash in a few fixes and
then edit the message. Maybe having to quit the editor is not that much
work after all.
As a bike-shedding side note: So far, all commands are verbs which
describe actions to take on that commit. In that sense a "fix deadbeef"
would be confusing: You don't fix deadbeef, you fix the predecessor
using deadbeef.
A bit of brainstorming (suck/use/smash/apply/join) does not convince me
of any of my alternatives, but maybe they convince someone else :)
Michael
P.S.: I thought there's some heavy rb-i rewrite in progress (sequencer
based or not?), but you cc'ed Dscho anyway who knows best.
Michael Haggerty (3): Better document the original repository layout. Set a couple more tags in the original repository. Add a command "fix" to rebase --interactive. Documentation/git-rebase.txt | 13 ++++++++----- git-rebase--interactive.sh | 39 +++++++++++++++++++++++++++++---------- t/lib-rebase.sh | 7 ++++--- t/t3404-rebase-interactive.sh | 41 +++++++++++++++++++++++++++++++++++++---- 4 files changed, 78 insertions(+), 22 deletions(-)