Re: [PATCH] rebase --fix: interactive fixup mode
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jan 8, 2012, 22:01 UTC
- Message-ID
- <20120108220127.GA4050@burratino>
- In-Reply-To
- <20120108213134.GA18671@ecki.lan>
Clemens Buchacher wrote:
Show 14 quoted lines
> --- a/Documentation/git-rebase.txt > +++ b/Documentation/git-rebase.txt > @@ -332,6 +332,15 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). > user edit that list before rebasing. This mode can also be used to > split commits (see SPLITTING COMMITS below). > > +--fix=<n>:: > + Searches commit history backwards from the current commit until the > + most recent merge commit, or until a maximum of <n> preceding commits > + (default: 20), and runs rebase -i <commit>^. The resulting range is > + typically large enough to contain recent commits which the user might > + want to edit, while avoiding the usually undesirable effects of > + rebasing a merge commit, which obviates the need to find a suitable > + base commit manually.
Funny. :) I wonder if this is possible to generalize, to something like
git rebase -i foo^{last-merge}or even something like
git rebase -i foo^{first:--merges}(where "<commit>^{first:<rev-list args>}" would mean something like "the first commit listed by "git rev-list <rev-list args> <commit>"). What do you think?