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(-)
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html