Quoting Wincent Colaiuta <win@xxxxxxxxxxx>: > El 18/6/2009, a las 23:55, Nanako Shiraishi escribió: > ... >> 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. I don't think it is about pretending to be perfect. If you are preparing a patch series to be reviewed, it is a minimum required courtesy to the reviewers to remove such earlier mistakes before submitting. It is called "making your series presentable." > 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>".) I think you didn't read the explanation by Junio (the second message I quoted) why that is only one of the options, and isn't a satisfying solution for him. He explicitly said that he doesn't want his momentum disrupted by having to go back before he finishes the series, while admitting that the way you suggest may fit other people's workflow better. As to the extra option, I don't like it, either (my original patch didn't have it). I added it only because Johannes Schindelin objected to the patch that the feature can trigger unexpectedly. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ -- 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