El 18/6/2009, a las 23:55, Nanako Shiraishi escribió:
Teach a new option, --autosquash, to the interactive rebase.
When the commit log message begins with "!fixup ...", and there
is a commit whose title begins with the same ..., automatically
modify the todo list of rebase -i so that the commit marked for
squashing come right after the commit to be modified, and change
the action of the moved commit from pick to squash.
This will help the use case outlined in
From: Junio C Hamano <gitster@xxxxxxxxx>
Date: Wed, 17 Jun 2009 09:33:19 -0700
Subject: Re: git rebase --interactive squash/squish/fold/rollup
Message-ID: <7vvdmurfao.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
Definitely a fairly common workflow for me. Faced with a sequence like
this:
[1/3] Cleanup
[2/3] Lay groundwork
[3/3] Implement feature
[4/4] Doh! more cleanup that should have gone in [1/3]
I usually just let 4/4 stand as a separate commit with a message like:
More cleanup of XYZ
Ideally this should have been included in commit abcd1234,
but wasn't noticed until too late.
Seeing as I'm not perfect, I don't necessarily spend time manipulating
the history to make it appear that I really am perfect.
Even so, if asked to imagine an ideal workflow for this scenario, I
don't really want a new switch for "git rebase -i", but rather the
ability to do "git commit --amend" on a non-head commit. (I know this
has come up on the list back in February under the subject "FEATURE
suggestion git commit --amend <ref>".)
Basically, if you do the following:
edit
git add foo
git commit -m "Cleanup"
edit
git add foo
git commit -m "Lay groundwork"
edit
git add foo
git commit -m "Implement feature"
# doh! found stuff that should have gone in in step one!
edit
git add foo
git commit --amend HEAD~3
My intention would be for git to actually:
1. Create a temporary throw-away commit (without updating the HEAD)
2. Do the equivalent of using "git rebase -i" to squash that
temporary commit into the HEAD~3 commit, providing you with the
opportunity to edit the adjust the commit message if necessary.
3. In the event of failure to replay the other commits on top, you
would want the process to dump you back where you started (same HEAD
as before, with same changes staged in the index) and an error message
informing you that the changes didn't apply cleanly and that you
should use "git rebase -i" instead to walk through the process manually.
At least for me that would be the ideal interface to this kind of
feature. I can't really see myself using these magic commit messages
and the --autosquash switch.
However, the "FEATURE suggestion git commit --amend <ref>" thread
caused a lot of objections to be raised. Things like:
- what if <ref> is a merge?
- what if there are merges between <ref> and the current HEAD?
- what if the amendment breaks reapplication of later commits?
- what if <ref> is not an ancestor of the current HEAD?
- what if <ref> is part of more than one branch? (and would the user
be confused if it was only rewritten on one branch?)
Basically as I see it, the kind of workflow being discussed here
should only be for the simple case of amending really simple histories
(basic topic branches) and should bail loudly if pretty much any of
the above conditions are true.
Cheers,
Wincent
--
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