rebasing trouble

rebasing trouble

[J. Bruce Fields]

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.

Re: rebasing trouble

[Junio C Hamano]

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

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

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

Re: rebasing trouble

[J. Bruce Fields]

On Thu, Jun 29, 2006 at 01:04:25PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > 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.
> 
> It matters of course.  Where is the "origin"?

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.

Re: rebasing trouble

[J. Bruce Fields]

On Thu, Jun 29, 2006 at 04:22:34PM -0400, bfields 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.

By the way, I should also have said:

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

--b.

Re: rebasing trouble

[J. Bruce Fields]

On Thu, Jun 29, 2006 at 03:47:23PM -0400, J. Bruce Fields wrote:
> 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.

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.

Re: rebasing trouble

[Junio C Hamano]

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

> 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?)

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

Re: rebasing trouble

[J. Bruce Fields]

On Thu, Jun 29, 2006 at 03:34:21PM -0700, Junio C Hamano wrote:
> 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
> 

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.

Re: rebasing trouble

[Junio C Hamano]

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

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

Yes.  Everybody loves to hate this syntax.