Clemens Buchacher wrote:
> --- 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?
--
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