Paolo Bonzini <bonzini@xxxxxxx> writes:
> +For example, `git commit --amend` also has this effect, and it can
> +happen that you use it even though you had already pushed to the
> +remote repository before amending your commit. You can then
> +use `git rebase` (with the --onto option) to transform the `--amend`
> +commit into a separate commit (as if you had not used the `--amend`
> +option). The situation is like this:
> +
> +------------
> + o---D---E origin/master
> + \
> + E'---F---G---H---I master
> +------------
> +
> +because the parent of the amended commit E' is D, that is
> +origin/master^. To avoid a forced update from master to
> +origin/master, you need the history to look like this:
> +
> +------------
> + o---D---E origin/master
> + \
> + E''---F'---G'---H'---I' master
> +------------
> +
> +You can achieve this with:
> +
> + git-rebase -s theirs --onto origin/master origin/master^ master
> +
> +The merge strategy `-s theirs` resolves conflicts in favor of the commits
> +being rebased---in this case, you know that the only conflicts will occur
> +when replaying E', and you definitely E'' to have those changes.
Isn't this a very risky thing to suggest as if it is a generally
applicable solution? What happens if others have already worked on top of
E and your history looked like this?
o---D---E---X---Y origin/master
\
E'---F---G---H---I master
The reader would want this history:
o---D---E---X---Y origin/master
\
E''--F'--G'--H'--I' master
where difference between Y and E'' contains the change between E and E'.
However, neither "rebase -s theirs --onto Y D master" (use of D is more in
the spirit of your original example than literal origin/master^) nor
"rebase -s theirs --onto Y origin/master^ master" (which is nonsense but
careless readers would be tempted to "adjust" your example to their
situation) would give such a tree. E'' should not have the same tree as
E' in this case.
I think I know why you wanted to do it in the original context without X
and Y. Use of "-s theirs" would allow you to record the tree of E'
without conflicts. But even that I do not agree is a good thing to do.
Because original E' was an amend of E, its log message explained
everything E did and more. You cannot leave that same commit message in
E''. What you did in E was already explained in the history, so now you
would want to talk about the incremental change on top of it when you
desribe E''. For that, replaying of E' must stop to allow you to fix up
the log message. It shouldn't silently go on.
Yes, you may want an easy way to say "the result should have the same tree
as E'" while replaying of E' on top of E _when_ you have to resolve the
conflict. But that is a separate issue ("git checkout $other_head --
$conflicted_paths", or somesuch). Using this in rebase is a horrible
example inviting misuse and a broken history, I 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
