{"thread":{"id":"15169","subject":"nicer frontend to get rebased tree?","startedAt":"2008-08-22T17:46:56Z","lastAt":"2008-08-25T09:36:45Z","messageCount":42,"participants":["Andi Kleen","Linus Torvalds","Avery Pennarun","Paolo Ciarrocchi","Jakub Narebski","Mikael Magnusson","Björn Steinbrink","Junio C Hamano","Paolo Bonzini","Marius Vollmer","Miklos Vajna","Theodore Tso","Ingo Molnar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"88165","messageId":"20080822174655.GP23334@one.firstfloor.org","threadId":"15169","inReplyTo":null,"subject":"nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-22T17:46:56Z","receivedAt":"2008-08-22T17:46:56Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"\nA common use case for git here is to just use it as a code \ndownloader without actually changing anything in the main branch.\n\nEspecially in Linux kernel land there seem to be quite a few tree\nwhich are frequently rebased, which means that the usual \"git pull -u\"\nusually leads to conflicts even when one hasn't changed anything\nat all and just wants the latest state of that tree.\n\nI found this initially quite frustrating (\"$@#!-git cannot \neven download new trees\"), until I managed to\nscript the necessary magic incarnations after some\ndocumentation study (which are quite a handfull to type manually). \n\nBut I presume that's a reasonable common usage. Would it \nmake sense to have some standard git sub command that does that? \n(\"get latest state of remote branch, doing what it takes to get it\")\nOr is there already one that I missed?\n\nThanks,\n-Andi\n\n-- \nak@linux.intel.com\n"},{"id":"88167","messageId":"alpine.LFD.1.10.0808221053080.3487@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"20080822174655.GP23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-22T17:55:35Z","receivedAt":"2008-08-22T17:55:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Aug 2008, Andi Kleen wrote:\n> \n> Especially in Linux kernel land there seem to be quite a few tree\n> which are frequently rebased, which means that the usual \"git pull -u\"\n> usually leads to conflicts even when one hasn't changed anything\n> at all and just wants the latest state of that tree.\n\nWhat drugs are you on?\n\n\"git pull\" is not \"download\". It's \"download and merge\".\n\nIf you just want download, use \"git fetch\". You should never _ever_ use \n\"git pull -u\", and the docs even tell you so.\n\nAnd if you _really_ haven't changed anything, then \"git pull\" will never \n_ever_ generate a conflict, not with -u, not without, not _ever_. \n\nSo you are really majorly confused about something here.\n\n\t\t\tLinus\n"},{"id":"88169","messageId":"32541b130808221056l75a3fd6bsa6c7933a1c3da60f@mail.gmail.com","threadId":"15169","inReplyTo":"20080822174655.GP23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-22T17:56:39Z","receivedAt":"2008-08-22T17:56:39Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen wrote:\n> But I presume that's a reasonable common usage. Would it\n> make sense to have some standard git sub command that does that?\n> (\"get latest state of remote branch, doing what it takes to get it\")\n> Or is there already one that I missed?\n\nIsn't that just\n\n git fetch somewhere branchname\n git reset --hard FETCH_HEAD\n\n?\n\nHave fun,\n\nAvery\n"},{"id":"88171","messageId":"20080822182718.GQ23334@one.firstfloor.org","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808221053080.3487@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-22T18:27:18Z","receivedAt":"2008-08-22T18:27:18Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"On Fri, Aug 22, 2008 at 10:55:35AM -0700, Linus Torvalds wrote:\n> \n> \n> On Fri, 22 Aug 2008, Andi Kleen wrote:\n> > \n> > Especially in Linux kernel land there seem to be quite a few tree\n> > which are frequently rebased, which means that the usual \"git pull -u\"\n> > usually leads to conflicts even when one hasn't changed anything\n> > at all and just wants the latest state of that tree.\n> \n> What drugs are you on?\n> \n> \"git pull\" is not \"download\". It's \"download and merge\".\n\nWell it's in pretty much every tutorial. And none of them\nsaid \"you have to figure out first if the person maintaining\nthe tree ever uses git rebase or not\".\n\nI also don't know of any good way to detect this. One has\nto just guess and try and error.\n\n> \n> If you just want download, use \"git fetch\". You should never _ever_ use \n> \"git pull -u\", and the docs even tell you so.\n\nWell git fetch does nothing by itself.\n\nYes I know it can be done (which I figured out after a extended\noddysee through git's great documentation), but it's quite complicated \nand definitely nowhere near intuitive.\n\n> And if you _really_ haven't changed anything, then \"git pull\" will never \n> _ever_ generate a conflict, not with -u, not without, not _ever_. \n\nSorry that's what I though initially too. But that's wrong. Just clone\ne.g. linux-next and then try to update it with pull a day later. \n\nrebase messed this all up majorly. And people use that unfortunately.\n\nIn fact most kernel trees except yours seem to do rebase sooner \nor later. \n\n-Andi\n"},{"id":"88172","messageId":"20080822183129.GR23334@one.firstfloor.org","threadId":"15169","inReplyTo":"32541b130808221056l75a3fd6bsa6c7933a1c3da60f@mail.gmail.com","subject":"Re: nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-22T18:31:29Z","receivedAt":"2008-08-22T18:31:29Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"On Fri, Aug 22, 2008 at 01:56:39PM -0400, Avery Pennarun wrote:\n> On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen wrote:\n> > But I presume that's a reasonable common usage. Would it\n> > make sense to have some standard git sub command that does that?\n> > (\"get latest state of remote branch, doing what it takes to get it\")\n> > Or is there already one that I missed?\n> \n> Isn't that just\n> \n> git fetch somewhere branchname\n> git reset --hard FETCH_HEAD\n> \n> ?\n\nMy script right now does.\n\ngit fetch origin\ngit fetch --tags origin\ngit remote update\ngit checkout master\ngit reset --hard origin/master\n\nSure I can continue using the script (until some change breaks it %),\nbut I was just asking if that was a common enough operation to deserve\nsome better support in standard git. It personally (as a relatively\ninexperienced git user) took me some time to come up with\nthis script and I found the original behaviour of git pull on rebased\ntrees double-plus unintuitive.\n\nJust an idea for improvement.\n\n-Andi\n\n-- \nak@linux.intel.com\n"},{"id":"88174","messageId":"4d8e3fd30808221203r1630addaodb87c0a8b34f0fd2@mail.gmail.com","threadId":"15169","inReplyTo":"20080822183129.GR23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-08-22T19:03:18Z","receivedAt":"2008-08-22T19:03:18Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 8/22/08, Andi Kleen wrote:\n> On Fri, Aug 22, 2008 at 01:56:39PM -0400, Avery Pennarun wrote:\n>> On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen wrote:\n>> > But I presume that's a reasonable common usage. Would it\n>> > make sense to have some standard git sub command that does that?\n>> > (\"get latest state of remote branch, doing what it takes to get it\")\n>> > Or is there already one that I missed?\n>>\n>> Isn't that just\n>>\n>> git fetch somewhere branchname\n>> git reset --hard FETCH_HEAD\n>>\n>> ?\n>\n> My script right now does.\n>\n> git fetch origin\n> git fetch --tags origin\n> git remote update\n> git checkout master\n> git reset --hard origin/master\n>\n\n\nwhy the two fetch?\nisn't git remote update sufficient?\n\nciao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"88178","messageId":"m37ia8sv49.fsf@localhost.localdomain","threadId":"15169","inReplyTo":"20080822183129.GR23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-08-22T19:34:00Z","receivedAt":"2008-08-22T19:34:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andi Kleen writes:\n\n> On Fri, Aug 22, 2008 at 01:56:39PM -0400, Avery Pennarun wrote:\n> > On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen wrote:\n\n> > > But I presume that's a reasonable common usage. Would it\n> > > make sense to have some standard git sub command that does that?\n> > > (\"get latest state of remote branch, doing what it takes to get it\")\n> > > Or is there already one that I missed?\n> > \n> > Isn't that just\n> > \n> > git fetch somewhere branchname\n> > git reset --hard FETCH_HEAD\n> > \n> > ?\n> \n> My script right now does.\n> \n> git fetch origin\n> git fetch --tags origin\n> git remote update\n> git checkout master\n> git reset --hard origin/master\n> \n> Sure I can continue using the script (until some change breaks it %),\n> but I was just asking if that was a common enough operation to deserve\n> some better support in standard git. It personally (as a relatively\n> inexperienced git user) took me some time to come up with\n> this script and I found the original behaviour of git pull on rebased\n> trees double-plus unintuitive.\n> \n> Just an idea for improvement.\n\nWith new enough git it should be enough to do\n\n $ git fetch origin\n $ git checkout origin/master # detaches HEAD\n\nOR\n\n $ git remote update\n $ git reset --hard origin/master # when on master\n\nBTW. it is stated countless time in documentation that published\nhistory should be not rebased, barring some extenuating circumstances\n(liku Junio's 'pu' (proposed updates) branch in git repository).\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"88179","messageId":"alpine.LFD.1.10.0808221233100.3487@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"20080822182718.GQ23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-22T19:36:58Z","receivedAt":"2008-08-22T19:36:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Aug 2008, Andi Kleen wrote:\n> \n> Well git fetch does nothing by itself.\n\nGit fetch does exactly what it should do by itself. \n\nIf you think it does \"nothing\", you're really confused.\n\nIt updates the \"remote\" branches - the ones you are downlaoding.\n\n> Sorry that's what I though initially too. But that's wrong. Just clone\n> e.g. linux-next and then try to update it with pull a day later. \n\nYou SHOULD NOT DO THAT!\n\nlinux-next is not a tree that you can track. It's a tree that you can \nfetch _once_ and then throw away.\n\nSo what you can do is to \"fetch\" linux-next, and test it. But you MUST \nNEVER EVER use it for anything else. You can't do development on it, you \ncannot rebase onto it, you can't do _anything_ with it.\n\nSo what you can do is to \"git fetch\" it (to download it), and then \"git \ncheckout\" to create a temporary checkout. That's pretty much all you can \ndo with linux-next.\n\n> rebase messed this all up majorly. And people use that unfortunately.\n\nExactly. Don't rebase. And don't base your development on somebody who \ndoes.\n\nAnd \"linux-next\" is literally just a temporary tree that is a merge of a \nlot of random trees. It has no future.\n\nRemember how I told you that you should never rebase?\n\n\t\t\tLinus\n"},{"id":"88186","messageId":"237967ef0808221311o2c4b1b38m7a6ab1664dff686@mail.gmail.com","threadId":"15169","inReplyTo":"20080822174655.GP23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2008-08-22T20:11:13Z","receivedAt":"2008-08-22T20:11:13Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2008/8/22 Andi Kleen :\n>\n> A common use case for git here is to just use it as a code\n> downloader without actually changing anything in the main branch.\n>\n> Especially in Linux kernel land there seem to be quite a few tree\n> which are frequently rebased, which means that the usual \"git pull -u\"\n> usually leads to conflicts even when one hasn't changed anything\n> at all and just wants the latest state of that tree.\n>\n> I found this initially quite frustrating (\"$@#!-git cannot\n> even download new trees\"), until I managed to\n> script the necessary magic incarnations after some\n> documentation study (which are quite a handfull to type manually).\n>\n> But I presume that's a reasonable common usage. Would it\n> make sense to have some standard git sub command that does that?\n> (\"get latest state of remote branch, doing what it takes to get it\")\n> Or is there already one that I missed?\n\nI'm pretty sure \"git pull --rebase\" will handle this case. You can set up\na config variable (per branch if you want) to make it the default so you\ncan just \"git pull\" again.\n\n-- \nMikael Magnusson\n"},{"id":"88187","messageId":"4d8e3fd30808221311w7c507abboecd0893def85a073@mail.gmail.com","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808221233100.3487@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-08-22T20:11:42Z","receivedAt":"2008-08-22T20:11:42Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Fri, Aug 22, 2008 at 9:36 PM, Linus Torvalds\n wrote:\n>\n>\n> On Fri, 22 Aug 2008, Andi Kleen wrote:\n>>\n>> Well git fetch does nothing by itself.\n>\n> Git fetch does exactly what it should do by itself.\n>\n> If you think it does \"nothing\", you're really confused.\n>\n> It updates the \"remote\" branches - the ones you are downlaoding.\n>\n>> Sorry that's what I though initially too. But that's wrong. Just clone\n>> e.g. linux-next and then try to update it with pull a day later.\n>\n> You SHOULD NOT DO THAT!\n>\n> linux-next is not a tree that you can track. It's a tree that you can\n> fetch _once_ and then throw away.\n>\n> So what you can do is to \"fetch\" linux-next, and test it. But you MUST\n> NEVER EVER use it for anything else. You can't do development on it, you\n> cannot rebase onto it, you can't do _anything_ with it.\n>\n> So what you can do is to \"git fetch\" it (to download it), and then \"git\n> checkout\" to create a temporary checkout. That's pretty much all you can\n> do with linux-next.\n\nLinus,\nsorry for the double posting.\n\nI agree, but I would like to point out a typical use case:\ngit clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\ngit remote add tip\ngit://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git\ngit remote update (to fetch both the trees, now i can \"track\" your\nbranch with a simple merge which will results in a fast forward)\ngit checkout -b tip-latest tip/master\n\nsince tip/master is often rebased (as pu or linux-next) what I do is\nthe following:\ngit branch -D tip-latest\ngit checkout -b tip-latest tip/master\n\nbut I guess lot of people would expect to \"throw away\" and \"checkout\nagain\" with a single git command.\n\nDoes it make sense?\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"88189","messageId":"alpine.LFD.1.10.0808221301300.3487@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808221233100.3487@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-22T20:29:39Z","receivedAt":"2008-08-22T20:29:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Aug 2008, Linus Torvalds wrote:\n> \n> So what you can do is to \"git fetch\" it (to download it), and then \"git \n> checkout\" to create a temporary checkout. That's pretty much all you can \n> do with linux-next.\n\n.. oh, and you can also do a throw-away branch and test what a merge would \nlook like when merged into linux-next. \n\nBasically there's a few sane sequences you can do with linux-next:\n\n - They all basically start with \"fetch and test\":\n\n\t# This obviously assumes you have set up 'linux-next' as a branch\n\t# earlier by either editing .git/config or using 'git remote add'\n\t# or something\n\n\tgit fetch linux-next\n\n\tgit checkout linux-next/master\n\t.. this will create a _temporary_ branch (\"detatched head\") ..\n\t.. you can now compile, install, boot this state ..\n\n repeat as necessary, but never actually do anything else with that \n detached branch (do a \"git checkout master\" to get back to a sane \n state)\n\nand after that you can do some things:\n\n - You can do throw-away work on that temporary branch: you can fix up \n crap when it doesn't compile etc, but you should always remember that \n it's purely throw-away, beacuse all of linux-next is throw-away, and \n gets re-created from scratch each time.\n\n In particular, one useful \"throw-away\" thing to do is to test what \n would happen if all the crud on linux-next is merged with whatever you \n have done youself. So assuming you're still on that throw-away branch \n (aka \"detached head\": \"git branch\" will say \"* (no branch)\" is your \n current branch), you can do things like\n\n\tgit merge master\n\n to merge in your own work on top of linux-next, but as a total \n throw-away (which is what you want: you can never use the state for \n anything else anyway, and you do _not_ want to pollute your real work \n in \"master\" by merging in the throw-away linux-next into that!)\n\nbut what you should _never_ do is to forget that you're on the throw-away \nbranch, and do any real development.\n\n\t\t\tLinus\n"},{"id":"88190","messageId":"alpine.LFD.1.10.0808221330090.3487@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"4d8e3fd30808221311w7c507abboecd0893def85a073@mail.gmail.com","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-22T20:33:50Z","receivedAt":"2008-08-22T20:33:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Aug 2008, Paolo Ciarrocchi wrote:\n> \n> since tip/master is often rebased (as pu or linux-next) what I do is\n> the following:\n> git branch -D tip-latest\n> git checkout -b tip-latest tip/master\n> \n> but I guess lot of people would expect to \"throw away\" and \"checkout\n> again\" with a single git command.\n\nI would literally suggest not using a branch at all. Yes, it works, but \nthis is the perfect usage case for \"no branch\" aka \"detached head\" usage, \nbecause \"git status\" will nicely tell you \"Not currently on any branch\" \nand \"git branch\" will point it out too.\n\nSo instead of using a real branch \"tip-latest\", just do\n\n\tgit checkout tip/master\n\nto not create a branch at all, since all you will eventually have to do is \nto delete it anyway, and saving the state for later would be actively \nwrong.\n\nThe \"git checkout\" will also have a nice message like\n\n\tNote: moving to \"tip/master\" which isn't a local branch\n\nand about how you _can_ save the state later if you want to (even if you \ndon't), which may look a bit scary, but once you get used to it it's \nactually not scary at all, but just reminds you that you did the right \nthing.\n\n\t\tLinus\n"},{"id":"88191","messageId":"20080822203606.GB1598@atjola.homenet","threadId":"15169","inReplyTo":"4d8e3fd30808221311w7c507abboecd0893def85a073@mail.gmail.com","subject":"Re: nicer frontend to get rebased tree?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-08-22T20:36:06Z","receivedAt":"2008-08-22T20:36:06Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.08.22 22:11:42 +0200, Paolo Ciarrocchi wrote:\n> since tip/master is often rebased (as pu or linux-next) what I do is\n> the following:\n> git branch -D tip-latest\n> git checkout -b tip-latest tip/master\n> \n> but I guess lot of people would expect to \"throw away\" and \"checkout\n> again\" with a single git command.\n\ngit reset --hard tip/master\n\nor just don't create a local branch at all and do testing on a detached\nHEAD, ie. just:\ngit checkout tip/master\n\nThat works after each fetch.\n\nBjörn\n"},{"id":"88192","messageId":"4d8e3fd30808221346g21999899s980be4411aabee0e@mail.gmail.com","threadId":"15169","inReplyTo":"20080822203606.GB1598@atjola.homenet","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-08-22T20:46:34Z","receivedAt":"2008-08-22T20:46:34Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 8/22/08, Björn Steinbrink wrote:\n> On 2008.08.22 22:11:42 +0200, Paolo Ciarrocchi wrote:\n>> since tip/master is often rebased (as pu or linux-next) what I do is\n>> the following:\n>> git branch -D tip-latest\n>> git checkout -b tip-latest tip/master\n>>\n>> but I guess lot of people would expect to \"throw away\" and \"checkout\n>> again\" with a single git command.\n>\n> git reset --hard tip/master\n\ngood point.\n\n> or just don't create a local branch at all and do testing on a detached\n> HEAD, ie. just:\n> git checkout tip/master\n>\n> That works after each fetch.\n\nyes, that's the same suggestion that i got from linus.\nThanks Bjorn, Linus.\n\nthese hints should probably get some visibility in lkml as well.\n\nciao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"88206","messageId":"7vvdxs7nhm.fsf@gitster.siamese.dyndns.org","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808221233100.3487@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-22T21:23:33Z","receivedAt":"2008-08-22T21:23:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 22 Aug 2008, Andi Kleen wrote:\n>> \n>> Well git fetch does nothing by itself.\n>\n> Git fetch does exactly what it should do by itself. \n>\n> If you think it does \"nothing\", you're really confused.\n>\n> It updates the \"remote\" branches - the ones you are downlaoding.\n>\n>> Sorry that's what I though initially too. But that's wrong. Just clone\n>> e.g. linux-next and then try to update it with pull a day later. \n>\n> You SHOULD NOT DO THAT!\n>\n> linux-next is not a tree that you can track. It's a tree that you can \n> fetch _once_ and then throw away.\n>\n> So what you can do is to \"fetch\" linux-next, and test it. But you MUST \n> NEVER EVER use it for anything else. You can't do development on it, you \n> cannot rebase onto it, you can't do _anything_ with it.\n\nExcept perhaps if you are maintaining your own set of patches on top of\n\"last official release from Linus\", you can test merge your changes into\nthe tip of linux-next of the day and make sure you are in good shape.\n\nOf course you need to discard the test merge after doing so. \n\nAn obvious question I can foresee is \"What if I had conflicts in the test\nmerge, and have to resolve it to see if my changes still work? I'd\nwant to rebase so that I do not have to resolve the conflict again when\nlinux-next matures and gets into Linus's tree. Now you tell me not to\nrebase onto it. What should I do?\"\n\nMy tentative answer is \"don't worry, rerere will help you next time\", but\nthere may be better options.\n"},{"id":"88260","messageId":"20080823071014.GT23334@one.firstfloor.org","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808221233100.3487@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-23T07:10:14Z","receivedAt":"2008-08-23T07:10:14Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"> Exactly. Don't rebase. And don't base your development on somebody who \n> does.\n\nThat's pretty much impossible in the current state of Linux development\nas far as I know.\n\n> Remember how I told you that you should never rebase?\n\nI suspect your recommendation does not match real world git use.\n\n-Andi\n"},{"id":"88261","messageId":"20080823071552.GU23334@one.firstfloor.org","threadId":"15169","inReplyTo":"m37ia8sv49.fsf@localhost.localdomain","subject":"Re: nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-23T07:15:52Z","receivedAt":"2008-08-23T07:15:52Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"> $ git remote update\n> $ git reset --hard origin/master # when on master\n> \n> BTW. it is stated countless time in documentation that published\n> history should be not rebased, barring some extenuating circumstances\n\nYes and people countless times ignore that recommendation and do \nit anyways (for good reasons). And then other users \nhave to deal with these rebased trees somehow.\n\nAnyways it is all solvable but right now ill supported\nin standard commands and the documentation does not really\ncover it. I was just asking (mostly for others to avoid\ngoing through the same pain as me) for that to be improved\nso that git becomes easier to use.\n\nSadly you guys don't even seem to want to recognize there\nis a problem :-( \n\n-Andi\n"},{"id":"88276","messageId":"loom.20080823T084556-260@post.gmane.org","threadId":"15169","inReplyTo":"20080823071552.GU23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-08-23T08:52:15Z","receivedAt":"2008-08-23T08:52:15Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"Andi Kleen firstfloor.org> writes:\n\n> \n> > $ git remote update\n> > $ git reset --hard origin/master # when on master\n> > \n> > BTW. it is stated countless time in documentation that published\n> > history should be not rebased, barring some extenuating circumstances\n> \n> Yes and people countless times ignore that recommendation and do \n> it anyways (for good reasons). And then other users \n> have to deal with these rebased trees somehow.\n> \n> Anyways it is all solvable but right now ill supported\n> in standard commands and the documentation does not really\n> cover it. I was just asking (mostly for others to avoid\n> going through the same pain as me) for that to be improved\n> so that git becomes easier to use.\n> \n> Sadly you guys don't even seem to want to recognize there\n> is a problem \n\nWhy are you saying so?\n\nYou now understand that your script:\ngit fetch origin\ngit fetch --tags origin\ngit remote update\ngit checkout master\ngit reset --hard origin/master\n\nit's far from being perfect, right?\n\ngit remote update is going to update all the remotes so you don't need the two\ngit fetch command.\n\nFurthermore, I just tried what was suggested in this thread:\npaolo@paolo-desktop:~/linux.trees.git$ git pull --rebase\nremote: Counting objects: 7867, done.\nremote: Compressing objects: 100% (1868/1868), done.\nremote: Total 5125 (delta 4373), reused 3839 (delta 3246)\nReceiving objects: 100% (5125/5125), 870.73 KiB | 187 KiB/s, done.\nResolving deltas: 100% (4373/4373), completed with 942 local objects.\nFrom git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip\n + dff643a...f8fcb0d auto-core-next -> tip/auto-core-next (forced update)\n b635ace..6a55617 auto-core-next-base -> tip/auto-core-next-base\n b635ace..6a55617 auto-cpus4096-next -> tip/auto-cpus4096-next\n b635ace..6a55617 auto-cpus4096-next-base -> tip/auto-cpus4096-next-base\n + 1f1fccc...696f6d1 auto-fastboot-next -> tip/auto-fastboot-next (forced update)\n b635ace..6a55617 auto-fastboot-next-base -> tip/auto-fastboot-next-base\n + cdca408...06d0224 auto-ftrace-next -> tip/auto-ftrace-next (forced update)\n b635ace..6a55617 auto-ftrace-next-base -> tip/auto-ftrace-next-base\n b635ace..6a55617 auto-generic-ipi-next -> tip/auto-generic-ipi-next\n[...]\n\nA nice single command that seems to achive your needs.\n\n\nCiao,\n Paolo\n"},{"id":"88282","messageId":"200808231121.41694.jnareb@gmail.com","threadId":"15169","inReplyTo":"20080823071552.GU23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-08-23T09:21:39Z","receivedAt":"2008-08-23T09:21:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andi Kleen wrote:\n> Jakub Narębski wrote:\n> > \n> > BTW. it is stated countless time in documentation that published\n> > history should be not rebased, barring some extenuating\n> > circumstances \n> \n> Yes and people countless times ignore that recommendation and do \n> it anyways (for good reasons). And then other users \n> have to deal with these rebased trees somehow.\n\nIf you are thinking about 'linux-next', it is exception rather than\nthe rule.\n\nBesides, Git is feature rich and allows many different workflows, so\nyou should _always_ read the Development/Contributing document for\nspecific project, if it exists. (See also explanation below on \ndifferent workflows). \n\n> Anyways it is all solvable but right now ill supported\n> in standard commands and the documentation does not really\n> cover it. I was just asking (mostly for others to avoid\n> going through the same pain as me) for that to be improved\n> so that git becomes easier to use.\n> \n> Sadly you guys don't even seem to want to recognize there\n> is a problem :-( \n\nFirst, there isn't just _one_ way to deal with non fast-forward \n(rebased) branch; there are many possible workflow wrt rebasing.\n\nThere can be something like 'pu' (proposed updates) branch in git \nrepository, which is basically read-only, rebuild from scratch merging \nbranch gathering topic branches which are not ready yet for 'next'\n(for development branch), like work in progress and the like. It is \nhere to be able to view/examine those topic branches, without crowding \npublic branch namespace. In short: it is only to view.\nWorkflow:\n $ git fetch origin OR git remote update\n\nThen there is something like 'linux-next' tree, which is also rebuild \nfrom scratch, and as far as I understand serves as gathering point for \ndifferent patches being prepared to enter Linux, and to resolve \nconflicts early. It is, if I understand correctly, to check if it \ncompiles and doesn't have bugs, and to test merging your work; _not_\nto base your own work on.\nWorkflow:\n $ git fetch origin OR git remote update\n $ git checkout origin/master # detaches HEAD / not on any branch\n\nFinally (or not: perhaps there are yet different workflows involving\nhistory rewriting) there are projects which use rebase based workflow.\nThe information about it should be on project homepage (or wiki).\nWorkflow:\n $ git pull --rebase # or configure it: branch.autosetuprebase etc.\n\n\nSecond, this is open source. If you feel that documentation needs \nimprovement, now that you have all this information, you can simply \nsend patch either to manpages, or to Git User's Manual. Trolling won't \nwork ;-P\n-- \nJakub Narebski\nPoland\n"},{"id":"88283","messageId":"48AFD764.7010605@gnu.org","threadId":"15169","inReplyTo":"20080823071014.GT23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-08-23T09:24:52Z","receivedAt":"2008-08-23T09:24:52Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Andi Kleen wrote:\n>> Exactly. Don't rebase. And don't base your development on somebody who \n>> does.\n> \n> That's pretty much impossible in the current state of Linux development\n> as far as I know.\n> \n>> Remember how I told you that you should never rebase?\n> \n> I suspect your recommendation does not match real world git use.\n\nI think if you have to rebase often, you're actually better off using\nstgit (patch queues is what the mercurial folks use instead of\noften-rebased local branches).\n\nDisclaimer: I am not an stgit user myself.\n\nPaolo\n"},{"id":"88295","messageId":"alpine.LFD.1.10.0808230853170.3363@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"20080823071014.GT23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-23T15:55:55Z","receivedAt":"2008-08-23T15:55:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Aug 2008, Andi Kleen wrote:\n>\n> > Exactly. Don't rebase. And don't base your development on somebody who \n> > does.\n> \n> That's pretty much impossible in the current state of Linux development\n> as far as I know.\n\nNote that the \"don't rebase\" (as usual) only concerns your published tree. \nYou can certainly rebase non-published stuff.\n\nAs to the \"don't base your development on somebody who does\" - base your \ndevelopment either on my tree (I don't rebase) or talk to the d*ck-head \nthat you _want_ to work with, but who rebases.\n\n> > Remember how I told you that you should never rebase?\n> \n> I suspect your recommendation does not match real world git use.\n\nA lot of the trees don't rebase. The rest of the trees may not realize \nthat somebody wants to work on top of them.\n\nAnd linux-next has _never_ been appropriate as a development base for \nother reasons, so forget about linux-next. It's to find merge conflicts \nand possibly boot/test failures of the trees it contains, not for anything \nelse.\n\n\t\t\tLinus\n"},{"id":"88296","messageId":"20080823163638.GW23334@one.firstfloor.org","threadId":"15169","inReplyTo":"48AFD764.7010605@gnu.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-23T16:36:38Z","receivedAt":"2008-08-23T16:36:38Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"On Sat, Aug 23, 2008 at 11:24:52AM +0200, Paolo Bonzini wrote:\n> Andi Kleen wrote:\n> >> Exactly. Don't rebase. And don't base your development on somebody who \n> >> does.\n> > \n> > That's pretty much impossible in the current state of Linux development\n> > as far as I know.\n> > \n> >> Remember how I told you that you should never rebase?\n> > \n> > I suspect your recommendation does not match real world git use.\n> \n> I think if you have to rebase often, you're actually better off using\n\n[ ] You read my original email.\n\nThe issue is not that I'm rebasing [1], but that other people I'm updating\ntrees from are rebasing all the time. And Linus and the others can\nsay \"don't rebase\" all the time -- that doesn't change the fact thato\nothers are rebasing anyways. And git's support for dealing with that seems\nto be quite poor.\n\n-Andi\n\n[1] Ok I do it occasionally, but that's not the problem here, and\nI don't have a real user base for my trees and the branches I'm \ndoing that on.\n"},{"id":"88297","messageId":"20080823164546.GX23334@one.firstfloor.org","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808230853170.3363@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-23T16:45:46Z","receivedAt":"2008-08-23T16:45:46Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"> Note that the \"don't rebase\" (as usual) only concerns your published tree. \n> You can certainly rebase non-published stuff.\n> \n> As to the \"don't base your development on somebody who does\" - base your \n\nThat's not practical for me. Maybe it's for you, but it doesn't really\nwork if you're sufficiently down the food tree. You just have to work\nwith what other maintainers have and you can't really yell at them\nwhen they do something inconvenient like you do all the time, because\nthey just ignore you then.\n\n> development either on my tree (I don't rebase) or talk to the d*ck-head \n> that you _want_ to work with, but who rebases.\n> \n> > > Remember how I told you that you should never rebase?\n> > \n> > I suspect your recommendation does not match real world git use.\n> \n> A lot of the trees don't rebase. The rest of the trees may not realize \n\nThat's not my experience, sorry (even on other other trees than linux-next,\nlinux-next was just an example). e.g. the original ACPI tree did it,\nthe x86 tree jungle does it, most of the other architecture trees do it,\nthe networking tree does it. etc.etc.\n\nThen for linux-next it's reasonable to say that one shouldn't \ndo development on top of it, but still if there is supposed\nto be a tester base for it it requires at least reasonable\nsupport in git for regular read-only download and right now that\nsupport is at best obscure and unobvious (to avoid stronger words)\n\n> And linux-next has _never_ been appropriate as a development base for \n> other reasons, so forget about linux-next. It's to find merge conflicts \n> and possibly boot/test failures of the trees it contains, not for anything \n> else.\n\nWell it sounds like most people except you get it \"wrong\". Or maybe\nit's more that your intended usage model just does not match what\npeople really do.\n\n-Andi \n"},{"id":"88298","messageId":"20080823165350.GY23334@one.firstfloor.org","threadId":"15169","inReplyTo":"200808231121.41694.jnareb@gmail.com","subject":"Re: nicer frontend to get rebased tree?","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-23T16:53:50Z","receivedAt":"2008-08-23T16:53:50Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"> If you are thinking about 'linux-next', it is exception rather than\n> the rule.\n\nNo you're wrong. The majority of Linux trees I have to deal with \ndo it now and then. And I must say I also understand why \nthey want it -- they want a clean history on top of Linus' tree.\nOtherwise there is no chance to find the own changes again\nafter a few thousands other merges.\n\n> First, there isn't just _one_ way to deal with non fast-forward \n> (rebased) branch; there are many possible workflow wrt rebasing.\n\nI don't doubt there are a million ways to do it somehow in\nall kinds of convoluted ways. And that's exactly the problem.\n\nThe only thing I asked for was that were as a simple standard way that\nis actually documented in the main documentation and the tutorials\nand doesn't require lots of strange commands.\n\nNot more not less. Right now that's not there as I know\nfrom my own experience.\n\nMaybe for you people who spend days thinking about git and\nhacking it these ways are all obvious, but for someone like\nme who just wants to use the tool it's definitely not easy\nto do currently.\n\nAnyways I'll shut up on this now because it sounds like\nyou people are not interested in improving the tool for \nnon power users. \n\n-Andi\n"},{"id":"88300","messageId":"alpine.LFD.1.10.0808231054400.3363@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"20080823164546.GX23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-23T17:58:55Z","receivedAt":"2008-08-23T17:58:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Aug 2008, Andi Kleen wrote:\n> > \n> > A lot of the trees don't rebase. The rest of the trees may not realize \n> \n> That's not my experience, sorry (even on other other trees than linux-next,\n> linux-next was just an example). e.g. the original ACPI tree did it,\n> the x86 tree jungle does it, most of the other architecture trees do it,\n> the networking tree does it. etc.etc.\n\nSo _complain_ to those people. Tell them that they are making your life \nharder. Let them know.\n\nI sure as hell let people know when they are making _my_ life harder. It \nhas helped. The networking tree stopped rebasing, and the x86 tree doesn't \ndo it for the topic branches (although I think it re-creates the \"common\" \nbranches all the time, kind of like linux-next).\n\nThat said, why the hell do you even care? You shouldn't base your work on \nother trees anyway. You should base your work on something as stable as \npossible. IOW, not necessariyl even my \"tree-of-the-day\", but actually try \nto do as much development based on real releases as possible.\n\nYeah, sometimes you need to synchronize with other people, but that really \nshould be avoided. Not because git doesn't do it well, but because any \ntime you have multiple people working in the same area, there is something \ngenerally WRONG. It's indicative that there is a lack of modularity when \npeople step on each others toes too much.\n\n> Then for linux-next it's reasonable to say that one shouldn't \n> do development on top of it, but still if there is supposed\n> to be a tester base for it it requires at least reasonable\n> support in git for regular read-only download and right now that\n> support is at best obscure and unobvious (to avoid stronger words)\n\nUmm. How obscure was it really to do\n\n\tgit fetch\n\tgit checkout\n\nHmm?\n\n\t\tLinus\n"},{"id":"88302","messageId":"20080823181827.GA15993@atjola.homenet","threadId":"15169","inReplyTo":"20080823164546.GX23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-08-23T18:18:27Z","receivedAt":"2008-08-23T18:18:27Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.08.23 18:45:46 +0200, Andi Kleen wrote:\n> Then for linux-next it's reasonable to say that one shouldn't \n> do development on top of it, but still if there is supposed\n> to be a tester base for it it requires at least reasonable\n> support in git for regular read-only download and right now that\n> support is at best obscure and unobvious (to avoid stronger words)\n\nSo, how would you make it less obscure and unobvious then the current\nmethod? The current method would be:\n\ngit fetch linux-next\ngit checkout linux-next/whatever\n\nWhich seems neither obscure nor unobvious to me...\n\nBjörn\n"},{"id":"88303","messageId":"alpine.LFD.1.10.0808231152250.3363@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"20080823181827.GA15993@atjola.homenet","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-23T18:56:27Z","receivedAt":"2008-08-23T18:56:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Aug 2008, Björn Steinbrink wrote:\n> \n> So, how would you make it less obscure and unobvious then the current\n> method? The current method would be:\n> \n> git fetch linux-next\n> git checkout linux-next/whatever\n> \n> Which seems neither obscure nor unobvious to me...\n\nOne thing that I admit we haven't done is _document_ this in some obvious \nplace.\n\nWhen you know git, it's really fairly obvious and straightforward. But for \nsomebody who doesn't, then _all_ the documentation is really about \nwell-maintained trees that don't rebase. We very much discourage rebasing, \nand none of the docs even really talk about how to handle it.\n\nThe linux-next tree in general is I think not as useful as people think it \ncould be. _I_ think it's been sold as something much bigger and more \nuseful than \"it's a tree where you see conflicts early, but you can't \nactually really _use_ it for anything\".\n\nSo part of it is not even necessarily about _git_ documentation, but about \nthe documentation for some of the trees that use git, but that aren't \nreally meant for others to then use. \n\n\t\tLinus\n"},{"id":"88317","messageId":"20080823200845.GA17374@atjola.homenet","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808231152250.3363@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-08-23T20:08:45Z","receivedAt":"2008-08-23T20:08:45Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.08.23 11:56:27 -0700, Linus Torvalds wrote:\n> On Sat, 23 Aug 2008, Björn Steinbrink wrote:\n> > So, how would you make it less obscure and unobvious then the current\n> > method? The current method would be:\n> > \n> > git fetch linux-next\n> > git checkout linux-next/whatever\n> > \n> > Which seems neither obscure nor unobvious to me...\n> \n> One thing that I admit we haven't done is _document_ this in some\n> obvious place.\n\nOne thing I experienced in #git is that people seem to have problems\nunderstanding remote tracking branches like linux-next/whatever in the\nabove example. Quite often, there have been requests like:\n\n How can I pull into all of my branches at once?\n\nAnd after some back and forth about pull being fetch+merge and that you\ncan only merge into your current branch etc. it usually turns out that\nthose folks just have a local branch for each remote tracking branch,\neven if all they want is just the state of the remote tracking branch\nanyway.\n\nSo they end up doing stuff like:\n\ngit checkout foo\ngit pull\ngit checkout my_work_on_top_of_foo\ngit rebase foo\n\nWhere \"foo\" is always just fast-forwarded to origin/foo.\n\nSo I think a major part of the problem is that remote tracking branches\nare not understood or at least not valued enough. Unfortunately, I have\nno real idea how we could improve that.\n\nOnce on #git, I explained how branches (ie. the refs in refs/heads) are\nspecial and that HEAD becomes a symbolic ref when you check them out,\nwhile it becomes a plain reference to a commit when you check out\nsomething else (tag, remote tracking branch, commit, whatever). And that\noperations like commit dereference HEAD until they find a non-symbolic\nref and update _that_ ref. I think that explanation worked quite well\nfor the person I was talking to and made him realize that you only need\nbranches when you really want create your own commits. But OTOH, telling\npeople that local branches are the actual special case might as well\nconfuse the hell out of them (me thinks). And besides that, I'm no good\nat writing \"static\" documentation anyway.\n\nBjörn\n"},{"id":"88322","messageId":"4d8e3fd30808231404y7293eb56g4fbed5565ab2aa9a@mail.gmail.com","threadId":"15169","inReplyTo":"20080823165350.GY23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-08-23T21:04:06Z","receivedAt":"2008-08-23T21:04:06Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 8/23/08, Andi Kleen wrote:\n[...]\n> Not more not less. Right now that's not there as I know\n> from my own experience.\n>\n> Maybe for you people who spend days thinking about git and\n> hacking it these ways are all obvious, but for someone like\n> me who just wants to use the tool it's definitely not easy\n> to do currently.\n>\n> Anyways I'll shut up on this now because it sounds like\n> you people are not interested in improving the tool for\n> non power users.\n\n\nthat's unfair Andi.\nyou got nice and detailed answers, for example you can track a\nrebased tree in your working directory using git pull --rebase.\nWhat's wrong with that?\n\nciao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"88323","messageId":"87k5e7fm3q.fsf_-_@uni-dortmund.de","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808231152250.3363@nehalem.linux-foundation.org","subject":"Documentating branches (was: nicer frontend to get rebased tree?)","fromName":"Marius Vollmer","fromEmail":"marius.vollmer@uni-dortmund.de","sentAt":"2008-08-23T21:38:33Z","receivedAt":"2008-08-23T21:38:33Z","isPatch":false,"sender":{"key":"marius.vollmer@uni-dortmund.de","avatar":null},"body":"Linus Torvalds writes:\n\n> So part of it is not even necessarily about _git_ documentation, but about \n> the documentation for some of the trees that use git, but that aren't \n> really meant for others to then use. \n\nIncidentally, can Git attach random blurbs to branches?\n\nI know that gitweb uses \".git/description\" to describe the whole\nrepository. Is there a way I can add descriptions for individual\nbranches?\n\nJunio periodically posts \"A note from the maintainer\" that explains how\nthe Git repository is structured and what each of the branches is for.\nIt would good if this information could be found in a standard location\nin the repository itself.\n\nPutting a README or HACKING (or MaintNote) file in the project sources\nitself doesn't seem right, since the sources can be offered from many\nrepositories, each with their own way of doing things.\n\nOne could extend the .git/description convention to\n.git/descriptions/refs/heads/master, say, and gitweb would put that next\nto the link for master.\n\nBut what about putting this information into proper objects, so that we\nhave the goodness of git to handle it. There could be a head called\n\"README\", and gitweb (and everybody else) could look there for blurbs.\n\nA simple convention should suffice, and maybe there is already one that\nI just don't know about. No changes to Git are needed. But\nimplementing it in gitweb would both be useful and would help people\nfinding them.\n"},{"id":"88324","messageId":"alpine.LFD.1.10.0808231440530.3363@nehalem.linux-foundation.org","threadId":"15169","inReplyTo":"4d8e3fd30808231404y7293eb56g4fbed5565ab2aa9a@mail.gmail.com","subject":"Re: nicer frontend to get rebased tree?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-23T21:52:37Z","receivedAt":"2008-08-23T21:52:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:\n>\n> you got nice and detailed answers, for example you can track a\n> rebased tree in your working directory using git pull --rebase.\n> What's wrong with that?\n\nNo, you really really cannot do that.\n\nIf the _tree_ you are tracking is itself rebasing (not just your own \ntree), then you cannot and absolutely SHOULD NOT use rebase (not directly, \nand not with \"git pull --rebase\".\n\nWhy?\n\nLet's look at what happens. Let's say that your history looks like\n\n\t... -> A -> B -> C -> a -> b -> c\n\nwhere the upper-case letters are from the tree you track, and the \nlower-case letters are the commits you added yourself.\n\nNow, let's say that the tree you track gets rebased, and in the process \n'B' is removed (because it turns out it was buggy), and A and C get \nmodified. What happens?\n\nYou now have\n\n\t... -> A -> B -> C -> a -> b -> c <- your branch\n\t \\\n\t other stuff -> A' -> C' <- newly rebased branch\n\n(where \"other stuff\" is whatever the remote branch was rebased on top \nof) and when you now try to rebase your stuff on top of the newly rebased \nbranch, you are going to end up trying to rebase all the _old_ commits \nthat weren't even yours (ie it's going to try to rebase A, B and C too!)\n\nAnd that's not what you want! It will potentially not only generate lots \nof conflicts (because A' and A aren't the same, and C' and C aren't the \nsame), and it will actually re-insert B - which was buggy - before it \nfinally gets to the commits _you_ actually did (a, b and c).\n\nSo no, you canno even sanely rebase on top of another persons rebased \ntree, because the _other_ person threw away his history, and since you \nremember their _old_ history, it's basically now you who are in charge of \nit.\n\nWhat you can do is to basically do\n\n\tgit fetch nasty-tree\n\tgit rebase C.. --onto nasty-tree\n\nie you can explicitly _tell_ rebase which commits you want to rebase. \nObviously, \"git rebase --interactive\" can help you do this (ie you can get \nthe whole list and edit out all the crud that you know isn't yours).\n\nBut this is why working on top of somebody elses tree that gets rebased is \nso hard. You lose all the history, because the other person basically \nthrew it away and started over.\n\nDon't get me wrong - it's _possible_ to do. See above about how you can \npick-and-choose the parts you decide you want to keep (your \"own\" stuff). \n\nIn fact, we could even do a form of \"rebase\" that only picks commits that \nyou committed yourself, and call it \"git rebase --my-commits nasty-tree\", \nand that would often do the right thing (assuming the source tree only \never rebases its own commits, of course! If it rebases other peoples \ncommits, it's so terminally broken that you should just refuse to work \nwith that tree, and shoot the maintainer)\n\nSo we could do more helper functions for this, but the fact is, it's a \nreally broken model. The real fix is to teach people not to rebase.\n\n\t\t\tLinus\n"},{"id":"88327","messageId":"4d8e3fd30808231509x6be6f83dyf5d53ebda8ab9424@mail.gmail.com","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808231440530.3363@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-08-23T22:09:21Z","receivedAt":"2008-08-23T22:09:21Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 8/23/08, Linus Torvalds wrote:\n>\n>\n> On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:\n>>\n>> you got nice and detailed answers, for example you can track a\n>> rebased tree in your working directory using git pull --rebase.\n>> What's wrong with that?\n>\n> No, you really really cannot do that.\n>\n> If the _tree_ you are tracking is itself rebasing (not just your own\n> tree), then you cannot and absolutely SHOULD NOT use rebase (not directly,\n> and not with \"git pull --rebase\".\n>\n> Why?\n>\n> Let's look at what happens. Let's say that your history looks like\n>\n> \t... -> A -> B -> C -> a -> b -> c\n>\n> where the upper-case letters are from the tree you track, and the\n> lower-case letters are the commits you added yourself.\n>\n[skipping a nice explanation, thanks]\n\nyou are right. But i thougth Andi was looking for simply having a\nworking tree in sync with a remote tree that is often rebased. That's\nwhat his script is doing.\nif the user is not adding any commit, isn't git pull --rebase the same\nof git fetch (or git remote update) +git checkout ?\n\nciao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"88328","messageId":"20080823221324.GA18472@atjola.homenet","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808231440530.3363@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-08-23T22:13:24Z","receivedAt":"2008-08-23T22:13:24Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.08.23 14:52:37 -0700, Linus Torvalds wrote:\n> On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:\n> >\n> > you got nice and detailed answers, for example you can track a\n> > rebased tree in your working directory using git pull --rebase.\n> > What's wrong with that?\n> \n> No, you really really cannot do that.\n> \n> If the _tree_ you are tracking is itself rebasing (not just your own \n> tree), then you cannot and absolutely SHOULD NOT use rebase (not directly, \n> and not with \"git pull --rebase\".\n> \n> Why?\n> \n> Let's look at what happens. Let's say that your history looks like\n> \n> \t... -> A -> B -> C -> a -> b -> c\n> \n> where the upper-case letters are from the tree you track, and the \n> lower-case letters are the commits you added yourself.\n> \n> Now, let's say that the tree you track gets rebased, and in the process \n> 'B' is removed (because it turns out it was buggy), and A and C get \n> modified. What happens?\n> \n> You now have\n> \n> \t... -> A -> B -> C -> a -> b -> c <- your branch\n> \t \\\n> \t other stuff -> A' -> C' <- newly rebased branch\n> \n> (where \"other stuff\" is whatever the remote branch was rebased on top \n> of) and when you now try to rebase your stuff on top of the newly rebased \n> branch, you are going to end up trying to rebase all the _old_ commits \n> that weren't even yours (ie it's going to try to rebase A, B and C too!)\n\nBut before the fetch step, you have remote/branch point to your old\nupstream. If \"pull --rebase\" remembers that and uses:\n\ngit rebase --onto remote/branch $old_upstream\n\nThat should work. And in fact, it actually seems to do that.\n\n\texec git-rebase $strategy_args --onto $merge_head \\\n\t${oldremoteref:-$merge_head}\n\nWith $oldremoteref being the remote tracking branch before the rebase.\n\nThat said, it seems very fragile. One \"git fetch\" and your upstream is\nlost and the next \"pull --rebase\" will fail.\n\nSo a somewhat less fragile way to do it would be:\n\ngit checkout -b foo origin/foo\ngit branch foo-upstream\n....\ngit fetch origin\ngit rebase --onto origin/foo foo-upstream\ngit branch -f foo-upstream origin/foo\n\nSo that you always have the current upstream for your branch available\nand can thus do a correct rebase. That at least doesn't break on its\nown, but still does when you forget to adjust your upstream reference.\n\nI don't actually like the idea, but maybe a refs/upstreams namespace\ncould be used by some script to keep track of the current upstreams of\nlocal branches and to help with such a workflow, if one really badly\nwants to do that... *hides*\n\nBjörn\n"},{"id":"88329","messageId":"20080823221728.GI23800@genesis.frugalware.org","threadId":"15169","inReplyTo":"87k5e7fm3q.fsf_-_@uni-dortmund.de","subject":"Re: Documentating branches (was: nicer frontend to get rebased tree?)","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-08-23T22:17:28Z","receivedAt":"2008-08-23T22:17:28Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, Aug 24, 2008 at 12:38:33AM +0300, Marius Vollmer wrote:\n> Junio periodically posts \"A note from the maintainer\" that explains how\n> the Git repository is structured and what each of the branches is for.\n> It would good if this information could be found in a standard location\n> in the repository itself.\n\nSee MaintNotes in the 'todo' branch.\n\nSee also Junio's post in this thread:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/79608/focus=79621\n"},{"id":"88330","messageId":"87fxovfk8s.fsf@uni-dortmund.de","threadId":"15169","inReplyTo":"87k5e7fm3q.fsf_-_@uni-dortmund.de","subject":"Re: Documentating branches","fromName":"Marius Vollmer","fromEmail":"marius.vollmer@uni-dortmund.de","sentAt":"2008-08-23T22:18:43Z","receivedAt":"2008-08-23T22:18:43Z","isPatch":false,"sender":{"key":"marius.vollmer@uni-dortmund.de","avatar":null},"body":"(\"Documentating\", wow... Sorry for that.)\n"},{"id":"88331","messageId":"87bpzjfjok.fsf_-_@uni-dortmund.de","threadId":"15169","inReplyTo":"20080823221728.GI23800@genesis.frugalware.org","subject":"Re: Documenting branches","fromName":"Marius Vollmer","fromEmail":"marius.vollmer@uni-dortmund.de","sentAt":"2008-08-23T22:30:51Z","receivedAt":"2008-08-23T22:30:51Z","isPatch":false,"sender":{"key":"marius.vollmer@uni-dortmund.de","avatar":null},"body":"Miklos Vajna writes:\n\n> On Sun, Aug 24, 2008 at 12:38:33AM +0300, Marius Vollmer wrote:\n>> Junio periodically posts \"A note from the maintainer\" that explains how\n>> the Git repository is structured and what each of the branches is for.\n>> It would good if this information could be found in a standard location\n>> in the repository itself.\n>\n> See MaintNotes in the 'todo' branch.\n\nYes, I found them there, but I wouldn't call this a good example that\nother people should imitate. \"MaintNotes in the todo branch\" seems more\nborn out of accident than by design. \"NOTES in the README branch\"\nalready sounds much better.\n\n> See also Junio's post in this thread:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/79608/focus=79621\n\nThanks, I will read the whole thread.\n"},{"id":"88332","messageId":"200808240049.19507.jnareb@gmail.com","threadId":"15169","inReplyTo":"20080823165350.GY23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-08-23T22:49:17Z","receivedAt":"2008-08-23T22:49:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andi Kleen wrote:\n> Jakub Narebski wrote:\n\n[By the way, could you try to keep attributions? It helps when writing\n responses to know who wrote which part. TIA]\n\n> > If you are thinking about 'linux-next', it is exception rather than\n> > the rule.\n> \n> No you're wrong. The majority of Linux trees I have to deal with \n> do it now and then. And I must say I also understand why \n> they want it -- they want a clean history on top of Linus' tree.\n> Otherwise there is no chance to find the own changes again\n> after a few thousands other merges.\n\nNumbers? I still think that in most cases projects shouldn't rebase\npublished history; and if they are, they should be educated (as Linus\nwrote elsewhere in the thread).\n \n> > First, there isn't just _one_ way to deal with non fast-forward \n> > (rebased) branch; there are many possible workflow wrt rebasing.\n> \n> I don't doubt there are a million ways to do it somehow in\n> all kinds of convoluted ways. And that's exactly the problem.\n\n_Workflows_. Not the way to deal with non fast-forward branches, not\nthe sequence of commands used, but the workflow, how branches are meant\nto be used.\n\nAnd that's three workflows which use rebase on published branches, not\nmillion. Perhaps they are a few more that I didn't thought about, but\nI don't think that it would be _much_ more.\n\n> The only thing I asked for was that were as a simple standard way that\n> is actually documented in the main documentation and the tutorials\n> and doesn't require lots of strange commands.\n> \n> Not more not less. Right now that's not there as I know\n> from my own experience.\n> \n> Maybe for you people who spend days thinking about git and\n> hacking it these ways are all obvious, but for someone like\n> me who just wants to use the tool it's definitely not easy\n> to do currently.\n\nThere is \"simple standard way\", although it might be not obvious to\nsomebody who is only beginner git user. And the problem is that\nfor \"us people\" it is _obvious_, so it is not documented. Documentation\nis usually best done, or at least best started by people who have\nfreshness enough to know what beginners might stumble on, what people\nnew to git might have problems with, while having enough information\nto actually write good, correct, exhaustive documentation.\n\nAnd the simple standard way is fetch+checkout (detaching checkout),\nat least for linux-next repository/project workflow.\n\n> Anyways I'll shut up on this now because it sounds like\n> you people are not interested in improving the tool for \n> non power users. \n\nWhy don't you send patch improving documentation (or command messages)\nthen, eh?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"88333","messageId":"48B09687.6070508@gnu.org","threadId":"15169","inReplyTo":"20080823163638.GW23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-08-23T23:00:23Z","receivedAt":"2008-08-23T23:00:23Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Andi Kleen wrote:\n> On Sat, Aug 23, 2008 at 11:24:52AM +0200, Paolo Bonzini wrote:\n>> Andi Kleen wrote:\n>>>> Exactly. Don't rebase. And don't base your development on somebody who \n>>>> does.\n>>> That's pretty much impossible in the current state of Linux development\n>>> as far as I know.\n>>>\n>>>> Remember how I told you that you should never rebase?\n>>> I suspect your recommendation does not match real world git use.\n>> I think if you have to rebase often, you're actually better off using\n> \n> [ ] You read my original email.\n> \n> The issue is not that I'm rebasing [1],\n\nYes sorry, I meant: if you have to rebase your branches on top of\nbranches that also rebase, you're actually better off using stgit.\n\nPaolo\n"},{"id":"88334","messageId":"20080823230110.GC18169@mit.edu","threadId":"15169","inReplyTo":"20080823165350.GY23334@one.firstfloor.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-08-23T23:01:10Z","receivedAt":"2008-08-23T23:01:10Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Aug 23, 2008 at 06:53:50PM +0200, Andi Kleen wrote:\n> > If you are thinking about 'linux-next', it is exception rather than\n> > the rule.\n> \n> No you're wrong. The majority of Linux trees I have to deal with \n> do it now and then. And I must say I also understand why \n> they want it -- they want a clean history on top of Linus' tree.\n> Otherwise there is no chance to find the own changes again\n> after a few thousands other merges.\n\nWhat I don't understand is in what context do you need to deal with\n\"the majority of Linux trees\"? Sure, the ext4 tree gets rebased all\nthe time. But that's because it's a \"leaf\" tree; it means that people\ncan't base development trees off of the ext4 tree as a result. But\nthen again, that's not what the ext4 git tree is intended for! It's\nlike in Java when you declare a class with the 'final' keyword; such\nclasses can't be subclassed.\n\nThe main use of the ext4 git tree is to allow people to more easily\npull changes into their own trees, either for building their own\nintegration trees, or their own personal private trees. It's simply a\nmuch more efficient way of applying a large number of patch queues.\nSo for example, when I build my personal kernel that I use on my\nlaptops, servers, et. al, I start with ext4 and pull in various\n\"fixes\" branches that I've needed over time to build a useful, stable\nkernel. So I have a personal merge script which does:\n\ngit branch -f master linus/master\ngit checkout master\ngit merge tp_smapi-0.37\ngit merge remotes/libata-dev/upstream-fixes\ngit merge remotes/ibm-acpi/for-upstream/acpi-release\ngit merge misc-fixes\ngit merge ext4dev\n\n... and the result is an integration tree that always treet as\nthrowaway, because I've merged in trees which are indeed throwaway.\nIf I *do* any development work on this tree, say I cheat and fix some\next4 bugs on this tree instead of the ext4 branch, I always will go\nback to the ext4 branch, and use \"git cherry-pick\" to move those\nchanges back to the ext4 tree.\n\n> > First, there isn't just _one_ way to deal with non fast-forward \n> > (rebased) branch; there are many possible workflow wrt rebasing.\n> \n> I don't doubt there are a million ways to do it somehow in\n> all kinds of convoluted ways. And that's exactly the problem.\n\nThere are, but the simpliest way to win (as the movie \"Wargames\" put\nit), is not to play. Just don't put commits on top of a non-terminal\ntrees; just use them to pull to create throw-away trees for\nbuilding/testing, for integration testing or to build your own\npersonal kernels. The only time when you really need to build on top\nof others' trees is if you have changes that depend on patches in\nanother tree, which in practice should happen rarely; and if it does,\nyou can ask the other maintainer to push the changes to Linus first.\n\nIn that case, what you can do is put a placeholder patch in your tree,\nwith a note in the commit log that this is a placeholder is pending\nsomeone else pushing the equivalent patch to Linus, and once they push\nit to Linus, when you do a rebase it will disappear. In practice,\nthis happens so rarely that doing this manually with manual\ncoordination between maintainers about who pushes a patch to Linus\nreally isn't that big of a deal.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"88335","messageId":"20080823230137.GD18169@mit.edu","threadId":"15169","inReplyTo":"20080823165350.GY23334@one.firstfloor.org","subject":"A proposed solution (Was: nicer frontend to get rebased tree?)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-08-23T23:01:37Z","receivedAt":"2008-08-23T23:01:37Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"Maybe what we need is a way in git to advertise that a particular\nbranch, when pulled into another repository, shouldn't be used as a\nbase for someone else to do development. The only question is what\ncan we do other than give a warning if someone tries to create a local\nbranch which tracks such a branch. One thought is to have a git\nconfig option which will forbid creating local branches that track an\n\"rebase-unstable\" branch, on the theory that the best thing to do with\nsuch workloads is to either use them as sources for \"git merge\" or a\ngit checkout creating a detached HEAD. \n\nOnce you've merged a rebase-unstable remote branch into a local\nbranch, the resulting local branch could be treated \"contaminated\"\nsuch that if the user tries to do any commits on such a local branch,\ngit issues a warning that you are committing changes onto a branch\nwhich should be considered throwaway.\n\nI guess the real question is whether we should be encoding quite this\nmuch policy into git. I think it would help make it easier to\nadvertise what is considered the preferred workflow, and if it can all\nbe turned off with a git-config option, people who don't want it can\nalways turn it off.\n\nWhat do folks think?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"88336","messageId":"7vzln3w8za.fsf@gitster.siamese.dyndns.org","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808231440530.3363@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-24T00:30:01Z","receivedAt":"2008-08-24T00:30:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Let's look at what happens. Let's say that your history looks like\n>\n> \t... -> A -> B -> C -> a -> b -> c\n>\n> where the upper-case letters are from the tree you track, and the \n> lower-case letters are the commits you added yourself.\n>\n> Now, let's say that the tree you track gets rebased, and in the process \n> 'B' is removed (because it turns out it was buggy), and A and C get \n> modified. What happens?\n>\n> You now have\n>\n> \t... -> A -> B -> C -> a -> b -> c <- your branch\n> \t \\\n> \t other stuff -> A' -> C' <- newly rebased branch\n>\n> (where \"other stuff\" is whatever the remote branch was rebased on top \n> of) and when you now try to rebase your stuff on top of the newly rebased \n> branch, you are going to end up trying to rebase all the _old_ commits \n> that weren't even yours (ie it's going to try to rebase A, B and C too!)\n> ...\n> What you can do is to basically do\n>\n> \tgit fetch nasty-tree\n> \tgit rebase C.. --onto nasty-tree\n>\n> ie you can explicitly _tell_ rebase which commits you want to rebase. \n\nWhich if I am reading git-rebase.sh right (mind you, this is not my code,\nso I may well be mistaken), that is what \"pull --rebase\" attempts to do\nwith the \"oldremoteref\" variable.\n"},{"id":"88438","messageId":"20080825093645.GA7741@elte.hu","threadId":"15169","inReplyTo":"alpine.LFD.1.10.0808231054400.3363@nehalem.linux-foundation.org","subject":"Re: nicer frontend to get rebased tree?","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-08-25T09:36:45Z","receivedAt":"2008-08-25T09:36:45Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> On Sat, 23 Aug 2008, Andi Kleen wrote:\n> > > \n> > > A lot of the trees don't rebase. The rest of the trees may not realize \n> > \n> > That's not my experience, sorry (even on other other trees than linux-next,\n> > linux-next was just an example). e.g. the original ACPI tree did it,\n> > the x86 tree jungle does it, most of the other architecture trees do it,\n\n[ thanks for the lovely charecterisation of -tip, it's appreciated.\n ]\n\n> > the networking tree does it. etc.etc.\n> \n> So _complain_ to those people. Tell them that they are making your \n> life harder. Let them know.\n> \n> I sure as hell let people know when they are making _my_ life harder. \n> It has helped. The networking tree stopped rebasing, and the x86 tree \n> doesn't do it for the topic branches (although I think it re-creates \n> the \"common\" branches all the time, kind of like linux-next).\n\nCorrect - we keep all topic branches append-only. (We rebase a topic \nonly in exceptional cases: if there's a complete restart from scratch, \nwhen the history is so messy or uninteresting that no-one would care \nabout it.)\n\nAnd we do more than that: even tip/master is becoming more and more \nappend-only. We are set up in a way that makes rebasing of a topic \nbranch painful for _us_ integrators already. That is because tip/master \nis a \"consumer\" of all the topic trees, in form of 'delta-integration', \nwhich just merges all updated topic branches ontop of tip/master.\n\nIf a topic tree is rebased, we feel the pain in tip/master: no easy \ndelta-integration run is possible anymore, we get a ton of conflicts due \nto the changed sha1's and due to the slightly changed content and the \nwhole topic tree has to be undone and re-merged. It's also harder to \ntrack changes and it's harder to trust the quality of a stream of \nchanges if they get rebased - etc.\n\nAlas, we dont rebase when we can avoid it.\n\nWe periodically 'reintegrate' the whole thing to create the linux-next \noutput branches and to get rid of the uninteresting hundreds of \ncriss-cross merges, but that's on a relatively slow scale of 1-2 weeks.\n\n( which is still too frequent for this to be truly append-only, but\n dependable enough for short-term development and obviously good for\n testing and regression-bisection activities. )\n\nWhen people ask me \"what should I use for development, tip/master?\", i \nsuggest them to use -git or a specific topic branch they are interested \nin. (and each topic branch is based on upstream -git as well.)\n\nSometimes if they are working in an area where there's known overlap \nwith multiple topics, people will send patches/pull-requests against \ntip/master. In that case we maintainers sort those out and 'spread' them \ninto individual topic branches - i.e. turn them into an append-only flow \nof changes.\n\nBut arch/x86 development is also a bit special: in the past year it has \ngathered almost as many developers and per kernel cycle commits as the \nnetworking tree, but compressed into a highly critical and hard to \ndebug/test ~190 KLOC codebase.\n\nThe networking tree is an order of magnitude larger at 1.5 MLOC, which \nmakes it statistically a lot less likely that commits would overlap in \nit - and makes it far more feasible to handle conflicts in the simplest \nand most robust way: by doing hierarchical maintenance with strict \nboundaries and thus _avoiding_ conflicts.\n\nHence we've set up the x86 tree as this 'forest of 160+ trees' which \ntopic trees iteract with each other intelligently and which get \nintegrated into a single \"kitchen sink\" test branch, tip/master.\n\n\tIngo\n"}]}