Clemens Buchacher <drizzd@xxxxxx> writes:
> 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.
I understand the problem you are trying to solve, but I am not sure if
this is a good idea from the UI point of view for two reasons.
- "We want to limit the extent of the operation to commits since the last
merge" is by itself a reasonable thing to ask, and I do not think it
should be limited to "rebase". If we had an extended SHA-1 syntax to
express it, for example, you may want to say "I want to see what I did
since the last merge" and run "git log $last_merge_before_HEAD..".
Perhaps HEAD~{merge} or something?
- If your "rebase --fix" is to "fix" things, what is "rebase -i" about?
Isn't it also about fixing? I imagine that ordinary people expect a
"fix" option that takes a parameter would take a commit to be fixed,
and drive the rebase machinery to quickly fix it; in other words,
$ git rebase --fix=':/^reword the greeting message'
may internally run "rebase -i $(git rev-parse ':/^rewor...')^", with
the insn sheet already prepared to "edit" the first commit in it, and
may even return the control back to the user without showing the insn
sheet in the editor.
Hmm?
--
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