{"thread":{"id":"4710","subject":"rebasing trouble","startedAt":"2006-06-29T19:47:23Z","lastAt":"2006-06-30T01:12:32Z","messageCount":8,"participants":["J. Bruce Fields","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"22825","messageId":"20060629194723.GD14287@fieldses.org","threadId":"4710","inReplyTo":null,"subject":"rebasing trouble","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-06-29T19:47:23Z","receivedAt":"2006-06-29T19:47:23Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"I must be missing something obvious:\n\nbfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^\nbfields@puzzle:linux-2.6$ git-describe\nv2.6.17-rc6-g28df955\nbfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin\nNothing to do.\nbfields@puzzle:linux-2.6$ git-describe\nv2.6.17\n\nSo the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable\nisn't a subset of origin, so this doesn't make sense to me.\n\nThe tree in question is actually at git://linux-nfs.org/~bfields/linux.git, if\nit matters.\n\n--b.\n"},{"id":"22827","messageId":"7vd5crranq.fsf@assigned-by-dhcp.cox.net","threadId":"4710","inReplyTo":"20060629194723.GD14287@fieldses.org","subject":"Re: rebasing trouble","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-29T20:04:25Z","receivedAt":"2006-06-29T20:04:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> I must be missing something obvious:\n>\n> bfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^\n> bfields@puzzle:linux-2.6$ git-describe\n> v2.6.17-rc6-g28df955\n> bfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin\n> Nothing to do.\n> bfields@puzzle:linux-2.6$ git-describe\n> v2.6.17\n>\n> So the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable\n> isn't a subset of origin, so this doesn't make sense to me.\n>\n> The tree in question is actually at git://linux-nfs.org/~bfields/linux.git, if\n> it matters.\n\nIt matters of course. Where is the \"origin\"?\n \n"},{"id":"22832","messageId":"20060629202234.GE14287@fieldses.org","threadId":"4710","inReplyTo":"7vd5crranq.fsf@assigned-by-dhcp.cox.net","subject":"Re: rebasing trouble","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-06-29T20:22:34Z","receivedAt":"2006-06-29T20:22:34Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jun 29, 2006 at 01:04:25PM -0700, Junio C Hamano wrote:\n> \"J. Bruce Fields\" writes:\n> \n> > I must be missing something obvious:\n> >\n> > bfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^\n> > bfields@puzzle:linux-2.6$ git-describe\n> > v2.6.17-rc6-g28df955\n> > bfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin\n> > Nothing to do.\n> > bfields@puzzle:linux-2.6$ git-describe\n> > v2.6.17\n> >\n> > So the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable\n> > isn't a subset of origin, so this doesn't make sense to me.\n> >\n> > The tree in question is actually at git://linux-nfs.org/~bfields/linux.git, if\n> > it matters.\n> \n> It matters of course. Where is the \"origin\"?\n\nI realized after I sent that that \"origin\" in that public repository actually\nisn't the same as \"origin\" in the local repo that I'm working on. So I just\nran a GIT_DIR=. git-fetch there, and now both branches agree.\n\n--b.\n"},{"id":"22834","messageId":"20060629203856.GG14287@fieldses.org","threadId":"4710","inReplyTo":"20060629202234.GE14287@fieldses.org","subject":"Re: rebasing trouble","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-06-29T20:38:56Z","receivedAt":"2006-06-29T20:38:56Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jun 29, 2006 at 04:22:34PM -0400, bfields wrote:\n> I realized after I sent that that \"origin\" in that public repository actually\n> isn't the same as \"origin\" in the local repo that I'm working on. So I just\n> ran a GIT_DIR=. git-fetch there, and now both branches agree.\n\nBy the way, I should also have said:\n\nbfields@puzzle:git$ git --version\ngit version 1.4.1.rc2\n\n--b.\n"},{"id":"22847","messageId":"20060629215725.GI14287@fieldses.org","threadId":"4710","inReplyTo":"20060629194723.GD14287@fieldses.org","subject":"Re: rebasing trouble","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-06-29T21:57:25Z","receivedAt":"2006-06-29T21:57:25Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jun 29, 2006 at 03:47:23PM -0400, J. Bruce Fields wrote:\n> I must be missing something obvious:\n> \n> bfields@puzzle:linux-2.6$ git checkout -b TMP nfs-client-stable^^^\n> bfields@puzzle:linux-2.6$ git-describe\n> v2.6.17-rc6-g28df955\n> bfields@puzzle:linux-2.6$ git-rebase --onto v2.6.17 origin\n> Nothing to do.\n> bfields@puzzle:linux-2.6$ git-describe\n> v2.6.17\n> \n> So the git-rebase just reset TMP to v2.6.17. But I know that nfs-client-stable\n> isn't a subset of origin, so this doesn't make sense to me.\n\nOops, sorry, I lied; nfs-client-stable *is* a subset of origin, since Linus\nmerged it.\n\nBut it *isn't* a subset of v2.6.17.\n\nSo the semantics of git-rebase just aren't quite what I expected. It first\nremoves anything that isn't in the given upstream branch, *then* rebases to the\ncommit given after --onto. Which may mean it throws out some stuff that is in\nthe upstream branch even though it isn't yet included as of the given commit.\n\nSo what I really meant to do was just\n\n\tgit-rebase v2.6.17\n\nAnd rereading the man page, I see that git-rebase was working exactly as\nadvertised. So I'm an idiot. In my defense, it is a little confusing: none of\nthe examples in the man page that use --onto actually need it, and the\n\"upstream\" argument probably should be described as a commit or something\ninstead of a branch.\n\n(What is --onto actually useful for?)\n\n--b.\n"},{"id":"22854","messageId":"7vlkrfoaky.fsf@assigned-by-dhcp.cox.net","threadId":"4710","inReplyTo":"20060629215725.GI14287@fieldses.org","subject":"Re: rebasing trouble","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-29T22:34:21Z","receivedAt":"2006-06-29T22:34:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> In my defense, it is a little confusing: none of\n> the examples in the man page that use --onto actually need it, and the\n> \"upstream\" argument probably should be described as a commit or something\n> instead of a branch.\n>\n> (What is --onto actually useful for?)\n\nThink of it as a replacement of cherry-picking series of patches\nfrom remotely related branches.\n\nFor example, I maintain two public branches \"master\" and\n\"next\", the former is supposed to be quite stable and the latter\nto contain sane proposed updates that need to be proven before\ngraduating to \"master\".\n\nSometimes I get patches that I have to apply on top of \"next\"\nbecause of textual dependency, but the changes are worthwhile to\nhave it in \"master\" earlier than the changes the other series\ndepends on.\n\n o---o---o---o---o master\n \\\n o---o---o---o---o next\n \\\n o---o---o good\n\n\t$ git checkout good\n $ git rebase --onto master next\n\n o---o---o---o---o master\n | \\\n | o---o---o good\n \\\n o---o---o---o---o next\n"},{"id":"22859","messageId":"20060629234502.GB10041@fieldses.org","threadId":"4710","inReplyTo":"7vlkrfoaky.fsf@assigned-by-dhcp.cox.net","subject":"Re: rebasing trouble","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-06-29T23:45:02Z","receivedAt":"2006-06-29T23:45:02Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jun 29, 2006 at 03:34:21PM -0700, Junio C Hamano wrote:\n> For example, I maintain two public branches \"master\" and\n> \"next\", the former is supposed to be quite stable and the latter\n> to contain sane proposed updates that need to be proven before\n> graduating to \"master\".\n> \n> Sometimes I get patches that I have to apply on top of \"next\"\n> because of textual dependency, but the changes are worthwhile to\n> have it in \"master\" earlier than the changes the other series\n> depends on.\n> \n> o---o---o---o---o master\n> \\\n> o---o---o---o---o next\n> \\\n> o---o---o good\n> \n> \t$ git checkout good\n> $ git rebase --onto master next\n> \n> o---o---o---o---o master\n> | \\\n> | o---o---o good\n> \\\n> o---o---o---o---o next\n> \n\nOK, so you're saying \"take everything in good but not in next, and try to apply\nit to master.\"\n\nI don't know why I find that syntax so counterintuitive. Something like\n\n\tgit checkout -b newgood master\n\tgit cherry-pick next..good\n\nwould seem more obvious. But I think this has been discussed before. OK,\nthanks for the explanation.\n\n--b.\n"},{"id":"22870","messageId":"7v3bdno39b.fsf@assigned-by-dhcp.cox.net","threadId":"4710","inReplyTo":"20060629234502.GB10041@fieldses.org","subject":"Re: rebasing trouble","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-30T01:12:32Z","receivedAt":"2006-06-30T01:12:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> I don't know why I find that syntax so counterintuitive. Something like\n>\n> \tgit checkout -b newgood master\n> \tgit cherry-pick next..good\n>\n> would seem more obvious.\n\nYes. Everybody loves to hate this syntax.\n"}]}