rebasing trouble

I must be missing something obvious:

bfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^ bfields@puzzle:linux-2.6$ git-describe v2.6.17-rc6-g28df955 bfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin Nothing to do. bfields@puzzle:linux-2.6$ git-describe v2.6.17

So the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable isn't a subset of origin, so this doesn't make sense to me.

The tree in question is actually at git://linux-nfs.org/~bfields/linux.git, if it matters.

--b.

"J. Bruce Fields" <bfields@fieldses.org> writes:

It matters of course.  Where is the "origin"?
 

On Thu, Jun 29, 2006 at 01:04:25PM -0700, Junio C Hamano wrote:

I realized after I sent that that "origin" in that public repository actually isn't the same as "origin" in the local repo that I'm working on. So I just ran a GIT_DIR=. git-fetch there, and now both branches agree.

--b.

On Thu, Jun 29, 2006 at 04:22:34PM -0400, bfields wrote:

By the way, I should also have said:

bfields@puzzle:git$ git --version git version 1.4.1.rc2

--b.

On Thu, Jun 29, 2006 at 03:47:23PM -0400, J. Bruce Fields wrote:

Oops, sorry, I lied; nfs-client-stable *is* a subset of origin, since Linus merged it.

But it *isn't* a subset of v2.6.17.

So the semantics of git-rebase just aren't quite what I expected. It first removes anything that isn't in the given upstream branch, *then* rebases to the commit given after --onto. Which may mean it throws out some stuff that is in the upstream branch even though it isn't yet included as of the given commit.

So what I really meant to do was just

	git-rebase v2.6.17

And rereading the man page, I see that git-rebase was working exactly as advertised. So I'm an idiot. In my defense, it is a little confusing: none of the examples in the man page that use --onto actually need it, and the "upstream" argument probably should be described as a commit or something instead of a branch.

(What is --onto actually useful for?)

--b.

"J. Bruce Fields" <bfields@fieldses.org> writes:

Think of it as a replacement of cherry-picking series of patches from remotely related branches.

For example, I maintain two public branches "master" and "next", the former is supposed to be quite stable and the latter to contain sane proposed updates that need to be proven before graduating to "master".

Sometimes I get patches that I have to apply on top of "next" because of textual dependency, but the changes are worthwhile to have it in "master" earlier than the changes the other series depends on.

 o---o---o---o---o master
      \
       o---o---o---o---o next
                        \
                         o---o---o good

	$ git checkout good
        $ git rebase --onto master next

 o---o---o---o---o master
     |            \
     |             o---o---o good
      \
       o---o---o---o---o next

On Thu, Jun 29, 2006 at 03:34:21PM -0700, Junio C Hamano wrote:

OK, so you're saying "take everything in good but not in next, and try to apply it to master."

I don't know why I find that syntax so counterintuitive.  Something like

	git checkout -b newgood master
	git cherry-pick next..good

would seem more obvious. But I think this has been discussed before. OK, thanks for the explanation.

--b.

"J. Bruce Fields" <bfields@fieldses.org> writes:

Yes.  Everybody loves to hate this syntax.