Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 6, 2008, 23:08 UTC
Message-ID: <7vfxrqrwjm.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <E1K4a1Q-0002hq-QE@fencepost.gnu.org>

Paolo Bonzini <bonzini@gnu.org> writes:

Show 30 quoted lines

> +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.