# rebasing trouble 8 messages from 2006-06-29 to 2006-06-30. Participants: J. Bruce Fields, Junio C Hamano. Thread: https://gitlist.dev/t/4710 ## J. Bruce Fields, 2006-06-29 19:47 Subject: rebasing trouble Message-ID: <20060629194723.GD14287@fieldses.org> URL: https://gitlist.dev/e/20060629194723.GD14287%40fieldses.org ``` 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. ``` ## Junio C Hamano, 2006-06-29 20:04 Subject: Re: rebasing trouble Message-ID: <7vd5crranq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd5crranq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060629194723.GD14287@fieldses.org> ``` "J. Bruce Fields" 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"? ``` ## J. Bruce Fields, 2006-06-29 20:22 Subject: Re: rebasing trouble Message-ID: <20060629202234.GE14287@fieldses.org> URL: https://gitlist.dev/e/20060629202234.GE14287%40fieldses.org In-Reply-To: <7vd5crranq.fsf@assigned-by-dhcp.cox.net> ``` On Thu, Jun 29, 2006 at 01:04:25PM -0700, Junio C Hamano wrote: > "J. Bruce Fields" 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. ``` ## J. Bruce Fields, 2006-06-29 20:38 Subject: Re: rebasing trouble Message-ID: <20060629203856.GG14287@fieldses.org> URL: https://gitlist.dev/e/20060629203856.GG14287%40fieldses.org In-Reply-To: <20060629202234.GE14287@fieldses.org> ``` 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. ``` ## J. Bruce Fields, 2006-06-29 21:57 Subject: Re: rebasing trouble Message-ID: <20060629215725.GI14287@fieldses.org> URL: https://gitlist.dev/e/20060629215725.GI14287%40fieldses.org In-Reply-To: <20060629194723.GD14287@fieldses.org> ``` 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. ``` ## Junio C Hamano, 2006-06-29 22:34 Subject: Re: rebasing trouble Message-ID: <7vlkrfoaky.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vlkrfoaky.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060629215725.GI14287@fieldses.org> ``` "J. Bruce Fields" 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 ``` ## J. Bruce Fields, 2006-06-29 23:45 Subject: Re: rebasing trouble Message-ID: <20060629234502.GB10041@fieldses.org> URL: https://gitlist.dev/e/20060629234502.GB10041%40fieldses.org In-Reply-To: <7vlkrfoaky.fsf@assigned-by-dhcp.cox.net> ``` 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. ``` ## Junio C Hamano, 2006-06-30 01:12 Subject: Re: rebasing trouble Message-ID: <7v3bdno39b.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bdno39b.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060629234502.GB10041@fieldses.org> ``` "J. Bruce Fields" 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. ```