Re: [PATCH] rebase --fix: interactive fixup mode
On 01/08/2012 10:31 PM, Clemens Buchacher wrote:
Show 23 quoted lines
> Interactive rebase is frequently used not to rebase history, but to
> manipulate recent commits. This is typically done using the following
> command:
>
> git rebase -i HEAD~N
>
> Where N has to be large enough such that the the range HEAD~N..HEAD
> contains the desired commits. At the same time, it should be small
> enough such that the range HEAD~N..HEAD does not include published
> commits or a merge commit. Otherwise, the user may accidentally change
> published history. Rebasing a merge commit can also have the generally
> undesirable effect of linearizing the merge history.
>
> In order to determine a suitable range automatically, it is a reasonable
> heuristic to rebase onto the most recent merge commit. It does not
> guarantee that published commits are not included -- indeed there is no
> way to do that. But, the range is usually large enough to contain the
> desired commits. Also, this mechanism works regardless of whether or not
> branch tracking has been configured.
>
> So instead of the above command, one can instead use the following:
>
> git rebase --fix
Two comments:
* The name "--fix" might be confusing because of its similarity to the
"fixup" command that can be specified in the interactive instructions file.
* I agree with you that "interactive rebase is frequently used not to
rebase history, but to manipulate recent commits". In fact, I use
interactive rebase *only* for manipulating recent commits and
non-interactive rebase *only* for changing commits' ancestry. I think
it is a good idea to make these two uses more distinct. For example, it
makes me nervous that I might mis-type the <upstream> parameter when I
am trying to touch up commits and end up inadvertently rebasing the
commits onto a new parent.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Michael Haggerty <mhagger@alum.mit.edu>