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 <dpotapov@xxxxxxxxx> wrote: > Subject: Re: "git merge" merges too much! > > > > > > > > > > $ 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 -- 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