Re: "git merge" merges too much!

On Tue, Dec 01, 2009 at 04:58:34PM -0500, Greg A. Woods wrote:

At Tue, 1 Dec 2009 23:50:57 +0300, Dmitry Potapov [off-list ref] wrote:
Subject: Re: "git merge" merges too much!

quoted

quoted

quoted

$ git branch new-foo foo

$ git rebase --onto newbase oldbase new-foo

Hmmm.... I'll have to think about that.  It makes some sense, but I
don't intuitively read the command-line parameters well enough to
predict the outcome in all of the scenarios I'm interested in.

what is "oldbase" there?  I'm guessing it means "base of foo" (and for
the moment, "new-foo" too)?

You have:

 o---o---o---o---o  newbase
       \
        o---o---o---o---o  oldbase
                         \
                          o---o---o  foo

Yes, sort of -- in the ideal situation, but not in my particular example
where "oldbase" is just a tag, not a real branch.

It does not matter whether it is tag or branch or just SHA-1. You can
use any two reference as newbase and oldbase. They specify two points
in DAG. The only thing that has to be a branch in my example is new-foo.

So yes, "oldbase" is in fact "base of foo".  Trickier still is when the
"oldbase" branch has one or more commits newer then "base of foo".  Does
Git not have a symbolic name for the true base of a branch?  I.e. is
there not some form of symbolic name for "N" in the following?

   o---o---o---o---o---o---o---o  master
            \
             o---o---N---o---o  release-1
                      \
                       o---o---o  local-release-1

You can always find SHA-1 for N using the following command:

  git merge-base release-1 local-release-1

but you do not have to do that to rebase your changes. You just can run:

   # create a copy of local-release-1, so it will not disappear
   git branch copy-release-1 local-release-1

   # rebase the branch to master
   git rebase --onto master release-1 copy-release-1


Dmitry