{"thread":{"id":"3009","subject":"RE: git pull on Linux/ACPI release tree","startedAt":"2006-01-08T18:28:50Z","lastAt":"2006-01-13T14:50:27Z","messageCount":21,"participants":["Brown, Len","Martin Langhoff","Junio C Hamano","Linus Torvalds","David S. Miller","Tony Luck","Luben Tuikov","Adrian Bunk","Willy Tarreau","Andreas Ericsson","Greg KH","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14312","messageId":"F7DC2337C7631D4386A2DF6E8FB22B3005A13505@hdsmsx401.amr.corp.intel.com","threadId":"3009","inReplyTo":null,"subject":"RE: git pull on Linux/ACPI release tree","fromName":"Brown, Len","fromEmail":"len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org","sentAt":"2006-01-08T18:28:50Z","receivedAt":"2006-01-08T18:28:50Z","isPatch":false,"sender":{"key":"len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org","avatar":null},"body":" \n>I know a lot of people react to this kind of usage with \"what's the\n>point of the source control system if you're just messing with patches\n>in and out of the tree all the time\" But as a subsystem maintainer,\n>you deal with a lot of changes and it's important to get a pristine\n>clean history when you push things to Linus.\n>\n>In fact, I do this so much that Linus's tree HEAD often equals my\n>origin when he pulls.\n>\n>Merges really suck and I also hate it when the tree gets cluttered\n>up with them, and Linus is right, ACPI is the worst offender here.\n>\n>Yes, we can grep the merges out of the shortlog or whatever, but that\n>merging crap is still physically in the tree.\n>\n>Just don't do it. Merge into a private branch for testing if you\n>don't want to rebuild trees like I do, but push the clean tree to\n>Linus.\n\nPerhaps the tools should try to support what \"a lot of people\"\nexpect, rather than making \"a lot of people\" do extra work\nbecause of the tools?\n\nCall me old fashioned, but I believe that tools are supposed to\nmake work easier, not harder.\n\n-Len\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14314","messageId":"46a038f90601081119r39014fbi995cc8b6e95774da@mail.gmail.com","threadId":"3009","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B3005A13505-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Martin Langhoff","fromEmail":"martin.langhoff-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2006-01-08T19:19:50Z","receivedAt":"2006-01-08T19:19:50Z","isPatch":false,"sender":{"key":"martin.langhoff-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"On 1/9/06, Brown, Len wrote:\n> Perhaps the tools should try to support what \"a lot of people\"\n> expect, rather than making \"a lot of people\" do extra work\n> because of the tools?\n\nI think it does. All the tricky stuff that David and Junio have been\ndiscussing is actually done very transparently by\n\n git-rebase \n\nNow, git-rebase uses git-format-patch | git-am so\nit sometimes has problems merging. In that case, you can choose to\neither resolve the problem (see the doco for how to signal to git-am\nthat you've resolved a conflict) or to cancel the rebase. If you\nchoose to cancel the rebase, do\n\n cp .git/refs/heads/{,}\n cat .git/HEAD_ORIG > .git/refs/heads/\n git-reset --hard\n rm -fr .dotest\n\nand you'll be back to where you started. Perhaps this could be rolled\ninto something like git-rebase --cancel to make it easier, but that's\nabout it. The toolchain definitely supports it.\n\ncheers,\n\n\nmartin\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14315","messageId":"7vace61plu.fsf@assigned-by-dhcp.cox.net","threadId":"3009","inReplyTo":"46a038f90601081119r39014fbi995cc8b6e95774da-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Junio C Hamano","fromEmail":"junkio-j9pdmedngrk@public.gmane.org","sentAt":"2006-01-08T19:33:49Z","receivedAt":"2006-01-08T19:33:49Z","isPatch":false,"sender":{"key":"junkio-j9pdmedngrk@public.gmane.org","avatar":null},"body":"Martin Langhoff writes:\n\n> On 1/9/06, Brown, Len wrote:\n>> Perhaps the tools should try to support what \"a lot of people\"\n>> expect, rather than making \"a lot of people\" do extra work\n>> because of the tools?\n>\n> I think it does. All the tricky stuff that David and Junio have been\n> discussing is actually done very transparently by\n>\n> git-rebase \n>\n> Now, git-rebase uses git-format-patch | git-am so\n> it sometimes has problems merging.\n\nCareful. I do not think rebase works across merges at all.\n\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14316","messageId":"Pine.LNX.4.64.0601081111190.3169@g5.osdl.org","threadId":"3009","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B3005A13505@hdsmsx401.amr.corp.intel.com","subject":"RE: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-08T19:41:28Z","receivedAt":"2006-01-08T19:41:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 8 Jan 2006, Brown, Len wrote:\n>\n> Perhaps the tools should try to support what \"a lot of people\"\n> expect, rather than making \"a lot of people\" do extra work\n> because of the tools?\n> \n> Call me old fashioned, but I believe that tools are supposed to\n> make work easier, not harder.\n\nThey DO.\n\nLen, you're doing EXTRA WORK that is pointless.\n\nJust stop doing the automated merges. Problems solved. It really is that \neasy. Don't do what David suggests - he does it because he's apparently \n_so_ comfortable with things that he prefers to do extra work just to keep \nhis trees extra clean (I actually would disagree - but git makes that \nfairly easy to do, so if you prefer to have as linear a history as \npossible, you can do it with git pretty easily).\n\nNow, I'm only complaining about _automated_ merges. If you have a reason \nto worry about my tree having clashes with your tree, do a real merge. For \nexample, in your latest pull, you had a \n\n\t\"pull linus into release branch\"\n\nmerge, where you merged my v2.6.15 tree. That makes perfect sense.\n\nWhat I object to is that there were _also_ two automated merges within ten \nhours or each other, with absolutely _zero_ development in your tree in \nbetween. Why did you do that in your development tree? By _definition_ you \nhad done zero development. You just tracked the development in _my_ tree.\n\nIn case you wonder, the two commits I'm talking about are:\n\n\tadd5b5ee992e40c9cd8697ea94c223628be162a7\n\t25da0974601fc8096461f3d3f7ca3aab8e79adfb\n\nand neither of them have any reason to be in a development tree. You \ndidn't develop them.\n\nThey are real merges, because you had a trivial patch in your tree \n(changing the acpi-devel mailing list address) that I didn't have, so when \nyou pulled, your end result was thus always different from something I had \n(so you did a real \"merge\", even though it was totally trivial), but the \npoint is that there is a difference between \"the ACPI development tree\" \nand \"the tree that has random ACPI patches and then tracks Linus' tree as \nclosely as possible\".\n\nSee?\n\nThat's the most egregious example. There's two unnecessary pulls on \nDecember 28 and 29th too (commits 0a5296dc and c1a959d8).\n\nYou can do\n\n\tgitk 0aec63e..f9a204e1 \n\nto see exactly what I see when I pulled from you. 11 commits, 5 of which \nare just trivial merges that are no development, just tracking _my_ tree. \nOf those, one makes sense (tracking a release).\n\n(NOTE NOTE NOTE! It does make sense to track my tree in case you do big \nchanges and you worry about clashes. Then you would want to synchronize \nthose big changes with my changes, so that you can resolve any clashes \nearly. So I'm not saying that tracking trees is always bad: I'm saying \nthat doing so _unnecessarily_ is bad, because it adds no value, and it \njust makes the history harder to read).\n\nNow, most people don't read the history. It gets messy enough quickly \nenough that it's hard to read anyway over time. My tree has tons of _real_ \nmerges anyway, since it's by definition the one that is used for most \nsynchronization, so my tree is always pretty hard to follow.\n\nBut my guess is that this probably makes it harder for _you_ to see what \nyou've done too. If you didn't merge with me, then \"git log\" would show \njust your own changes at the top, and that's likely what you care most \nabout anyway, no?\n\nAlso, if you didn't pull from me, and you decided that you needed to re-do \nyour tree (let's say that you notice that one of your commits was bad \n_before_ you ask me to pull from your tree), then you'd also have an \neasier time re-creating your own development without that buggy change, \nexactly because _your_ tree wouldn't have my changed mixed up in it.\n\nSo your merges likely make git harder to use for you, not easier.\n\n\t\tLinus\n"},{"id":"14317","messageId":"Pine.LNX.4.64.0601081141450.3169@g5.osdl.org","threadId":"3009","inReplyTo":"46a038f90601081119r39014fbi995cc8b6e95774da@mail.gmail.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-08T19:56:21Z","receivedAt":"2006-01-08T19:56:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 9 Jan 2006, Martin Langhoff wrote:\n> \n> I think it does. All the tricky stuff that David and Junio have been\n> discussing is actually done very transparently by\n> \n> git-rebase \n\nYes, it's fairly easy to do. That said, I would actually discourage it. I \nhaven't said anything to David, because he is obviously very comfy with \nthe git usage, and it _does_ result in cleaner trees, so especially since \nthe networking code ends up being the source of a lot of changes, the \nextra cleanup stage that David does might actually be worth it for that \ncase.\n\nBut git is actually designed to have parallel development, and what David \ndoes is to basically artificially linearize it. We merge between us often \nenough that it doesn't really end up losing any historical information \n(since David can't linearize the stuff that we already merged), but in \n_theory_ what David does actually does remove the historical context.\n\nSo \"git-rebase\" is a tool that is designed to allow maintainers to (as the \ncommand says) rebase their own development and re-linearize it, so that \nthey don't see the real history. It's basically the reverse of what Len is \ndoing - Len mixes up his history with other peoples history in order to \nkeep them in sync, while David bassically \"re-does\" his history to be on \ntop of mine (to keep it _separate_).\n\nThe \"git-rebase\" means that David will always see the development he has \ndone/merged as being \"on top\" of whatever my most recent tree is. It's \nactually a bit scary, because if something goes wrong when David re-bases \nthings, he'll have to clean things up by hand, and git won't help him \nmuch, but hey, it works for him because (a) things seldom go wrong and (b) \nhe appears so comfortable with the tool that he _can_ fix things up when \nthey do go wrong.\n\nAnd yes, git-rebase can be very convenient. It has some problems too \n(which is the other reason I don't try to convince other maintainers to \nuse it): because it re-writes history, a change that _might_ have worked \nin its original place in history might no longer work after a rebase if it \ndepended on something subtle that used to be true but no longer is in the \nnew place that it has been rebased to.\n\nWhich just means that a commit that was tested and found to be working \nmight suddenly not work any more, which can be very surprising (\"But I \ndidn't change anything!\").\n\nOn the other hand, this is no different from doing a merge of two \nindependent streams of development, and getting a new bug that didn't \nexist in either of the two, just because they changed the assumptions of \neach other (ie not a _mismerge_, but simply two developers changing \nsomething that the other depended on it, and the bug only appears when \nboth the working trees are merged and the end result no longer works).\n\nSo my suggested git usage is to _not_ play games. Neither do too-frequent\nmerges _nor_ play games with git-rebase.\n\nThat said, git-rebase (and associated tools like \"git-cherry-pick\" etc) \ncan be a very powerful tool, especially if you've screwed something up, \nand want to clean things up. Re-doing history because you realized that a \nyou did something stupid that you don't want to admit to anybody else.\n\nSo trying out git-rebase and git-cherry-pick just in case you decide to \nwant to use them might be worthwhile. Making it part of your daily routine \nlike David has done? Somewhat questionable, but hey, it seems to be \nworking for David, and it does make some things much easier, so..\n\n\t\t\tLinus\n"},{"id":"14318","messageId":"Pine.LNX.4.64.0601081156430.3169@g5.osdl.org","threadId":"3009","inReplyTo":"7vace61plu.fsf@assigned-by-dhcp.cox.net","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-08T19:57:32Z","receivedAt":"2006-01-08T19:57:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 8 Jan 2006, Junio C Hamano wrote:\n> \n> Careful. I do not think rebase works across merges at all.\n\nRight. You have to do one or the other (rebase your changes to another \ntree _or_ merge another tree into your changes), but not mix the two.\n\n\t\tLinus\n"},{"id":"14320","messageId":"20060108.123525.41739629.davem@davemloft.net","threadId":"3009","inReplyTo":"Pine.LNX.4.64.0601081141450.3169@g5.osdl.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"David S. Miller","fromEmail":"davem@davemloft.net","sentAt":"2006-01-08T20:35:25Z","receivedAt":"2006-01-08T20:35:25Z","isPatch":false,"sender":{"key":"davem@davemloft.net","avatar":null},"body":"From: Linus Torvalds \nDate: Sun, 8 Jan 2006 11:56:21 -0800 (PST)\n\n> So my suggested git usage is to _not_ play games. Neither do too-frequent\n> merges _nor_ play games with git-rebase.\n> \n> That said, git-rebase (and associated tools like \"git-cherry-pick\" etc) \n> can be a very powerful tool, especially if you've screwed something up, \n> and want to clean things up. Re-doing history because you realized that a \n> you did something stupid that you don't want to admit to anybody else.\n> \n> So trying out git-rebase and git-cherry-pick just in case you decide to \n> want to use them might be worthwhile. Making it part of your daily routine \n> like David has done? Somewhat questionable, but hey, it seems to be \n> working for David, and it does make some things much easier, so..\n\nThe time at which I do the by-hand rebasing the most are the weeks\nleading up to a major release. The reason is to integrate bug fixes\nthat I know conflict with the 80-odd patches I have queued up for the\nnext development phase, or that I simply want integrated so that no\n_future_ development patches create conflicts.\n\nI think merges with conflicts that need to get resolved by hand create\na lot of noise and useless information and therefore to me they are\npointless. But this is just my opinion. It simply works easier to me\nto shuffle the patches in by hand and deal with the rejects one by\none. It's very much akin to how Andrew's -mm tree works.\n\nI think a clean history is worth an extra few minutes of someone's\ntime. And note that subsystem development is largely linear anyways.\n"},{"id":"14321","messageId":"12c511ca0601081250h726b0e14u7703f9d6910891ee@mail.gmail.com","threadId":"3009","inReplyTo":"Pine.LNX.4.64.0601081156430.3169@g5.osdl.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Tony Luck","fromEmail":"tony.luck@intel.com","sentAt":"2006-01-08T20:50:27Z","receivedAt":"2006-01-08T20:50:27Z","isPatch":false,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":"I'll try to update the using-topic-branches document to capture this.\nSome of the problem is that it doesn't quite capture what I'm doing\nwith my test/release branches.\n\nMy release branch really is just used as a transfer point to Linus.\nI usually[1] don't leave patches sitting in \"release\" for long enough\nthat I'll be tempted to merge in from Linus ... once I decide that\nsome patches are ready to go to Linus I'll update \"release\" from Linus\n(which will be a fast-forward, so no history) merge in the topic\nbranches, do one final sanity build, push to kernel.org and send\nthe \"please pull\" e-mail.\n\nThe huge majority of my \"automatic update from upstream\" merges\ngo into my test branch ... which never becomes part of the real\nhistory as I never ask Linus to pull from it.\n\n-Tony\n\n[1] Sometimes I goof on this because I forget that I've applied\na trivial patch directly to the release branch without going through\na topic branch. I think I'll fix my update script to check for this case.\n"},{"id":"14322","messageId":"20060108212057.79825.qmail@web31815.mail.mud.yahoo.com","threadId":"3009","inReplyTo":"Pine.LNX.4.64.0601081141450.3169@g5.osdl.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-01-08T21:20:57Z","receivedAt":"2006-01-08T21:20:57Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n> So trying out git-rebase and git-cherry-pick just in case you decide to \n> want to use them might be worthwhile. Making it part of your daily routine \n> like David has done? Somewhat questionable, but hey, it seems to be \n> working for David, and it does make some things much easier, so..\n\nHow about this usage (branch == tree):\n\nTree A (your tree)\n Tree B (project B, dependent on Tree A)\n Tree C (project C, dependent on project B)\n\n(i.e. diff(C-A) = diff(C-B) + diff(B-A))\n\nYour tree is pulled into Tree A as often as your tree\nchanges and it just fast forwards.\n\nIf I want to run project B with your latest tree, then\nI resolve/merge from tree A to tree B, compile B\nand run it.\n\nIf I want to run project C and project B with your\nlatest tree, I resolve/merge from tree A to tree B\nand from tree B to tree C, compile C and run it.\n\nIn such cases, are you saying that you'd prefer to\npull from Tree B and Tree C (depending on your needs)?\n\nAnother question:\nSometimes, a fix for project B finds its way into\ntree C (project C) (since C depended on that fix in B).\nNow I'd like to pull that particular fix, identified by\nits SHA, into project B, and nothing else, for this I can\nuse git-cherry-pick, right?\n\nAnd lastly, is there a tool whereby I can \"see\" changes\nbetween repos, kind of like git-diff but being able to\ngive URLs too?\n\n Luben\n"},{"id":"14325","messageId":"20060108230611.GP3774@stusta.de","threadId":"3009","inReplyTo":"Pine.LNX.4.64.0601081111190.3169-hNm40g4Ew95AfugRpC6u6w@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Adrian Bunk","fromEmail":"bunk-hej8db2gnd6zqb+pc5nmwq@public.gmane.org","sentAt":"2006-01-08T23:06:11Z","receivedAt":"2006-01-08T23:06:11Z","isPatch":false,"sender":{"key":"bunk-hej8db2gnd6zqb+pc5nmwq@public.gmane.org","avatar":null},"body":"On Sun, Jan 08, 2006 at 11:41:28AM -0800, Linus Torvalds wrote:\n>...\n> What I object to is that there were _also_ two automated merges within ten \n> hours or each other, with absolutely _zero_ development in your tree in \n> between. Why did you do that in your development tree? By _definition_ you \n> had done zero development. You just tracked the development in _my_ tree.\n>...\n\nMy impression is that you and Len are talking at different levels.\n\nI can't speak for Len, but let me try to describe a problem in this area \nI don't know the solution for:\n\nConsider I want to do the following:\n1. update my tree daily from your tree\n2. include 10 patches per week into my tree\n3. ask you once a month to pull from my tree\n\nHow should step 1 be done?\n\nIn CVS, I'd do a \"cvs update -dP .\"\nIn cogito, the equivalent command seems to be \"cg-update\".\n\nCVS has no problems if I have changed MAINTAINERS in one place and it \nchanges daily in your tree in other places, but how do I do the same in \ngit/cogito without creating the merges you don't want to see?\n\nThe solution might be described somewhere in TFM, but this is the class \nof problems people like me run into when the goal is simply a git tree \nto both track your tree and send changes to you without any interest in \nadvanced SCM knowledge.\n\n> \t\tLinus\n\ncu\nAdrian\n\n-- \n\n \"Is there not promise of rain?\" Ling Tan asked suddenly out\n of the darkness. There had been need of rain for many days.\n \"Only a promise,\" Lao Er said.\n Pearl S. Buck - Dragon Seed\n\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14327","messageId":"20060108235325.GJ7142@w.ods.org","threadId":"3009","inReplyTo":"20060108230611.GP3774-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Willy Tarreau","fromEmail":"willy@w.ods.org","sentAt":"2006-01-08T23:53:25Z","receivedAt":"2006-01-08T23:53:25Z","isPatch":false,"sender":{"key":"willy@w.ods.org","avatar":null},"body":"Hi Adrian,\n\nOn Mon, Jan 09, 2006 at 12:06:11AM +0100, Adrian Bunk wrote:\n> On Sun, Jan 08, 2006 at 11:41:28AM -0800, Linus Torvalds wrote:\n> >...\n> > What I object to is that there were _also_ two automated merges within ten \n> > hours or each other, with absolutely _zero_ development in your tree in \n> > between. Why did you do that in your development tree? By _definition_ you \n> > had done zero development. You just tracked the development in _my_ tree.\n> >...\n> \n> My impression is that you and Len are talking at different levels.\n> \n> I can't speak for Len, but let me try to describe a problem in this area \n> I don't know the solution for:\n> \n> Consider I want to do the following:\n> 1. update my tree daily from your tree\n> 2. include 10 patches per week into my tree\n> 3. ask you once a month to pull from my tree\n> \n> How should step 1 be done?\n\nI believe we all have the same problem. The only solution I found for\nthis was to proceed like David described. I know even have a 'git-patches'\ndirectory next to my git repo to keep the resulting patches after I do a\n'git-format-patch --mbox'.\n\nWhen Linus called it the 'stupid content tracker', he was half right.\nIn fact, it's more a 'changes tracker' than a 'content tracker'. It\nlogs everything you and others do, so if you don't want your operations\nto appear on others' history, you have to hide them by working on\ntemporary trees to generate the patches you will use later.\n\nAt first I found this very annoying, but finally, it's a way to ensure\nthat I always have clean and ordered patches. It's not much different\nfrom what I was doing by hand previously, it's just that all git-xxx\noperations take much longer time, possibly because of the compression.\nOn the other hand, its ability to understand mbox saves me some time.\n\n> In CVS, I'd do a \"cvs update -dP .\"\n> In cogito, the equivalent command seems to be \"cg-update\".\n> \n> CVS has no problems if I have changed MAINTAINERS in one place and it \n> changes daily in your tree in other places, but how do I do the same in \n> git/cogito without creating the merges you don't want to see?\n> \n> The solution might be described somewhere in TFM, but this is the class \n> of problems people like me run into when the goal is simply a git tree \n> to both track your tree and send changes to you without any interest in \n> advanced SCM knowledge.\n\nWhat sometimes worries me is that some operations seem so much complicated\nthat there is a high risk of doing the wrong thing, and I'm not certain\nthat this will reduce the number of mistakes I do in a month, compared\nto manual patching. I became a real addict to 'git-reset --hard' ...\n\n> cu\n> Adrian\n\nRegards,\nWilly\n\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14329","messageId":"Pine.LNX.4.64.0601081643090.3169@g5.osdl.org","threadId":"3009","inReplyTo":"20060108212057.79825.qmail@web31815.mail.mud.yahoo.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-09T01:13:47Z","receivedAt":"2006-01-09T01:13:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 8 Jan 2006, Luben Tuikov wrote:\n>\n> How about this usage (branch == tree):\n> \n> Tree A (your tree)\n> Tree B (project B, dependent on Tree A)\n> Tree C (project C, dependent on project B)\n> \n> (i.e. diff(C-A) = diff(C-B) + diff(B-A))\n> \n> Your tree is pulled into Tree A as often as your tree\n> changes and it just fast forwards.\n> \n> If I want to run project B with your latest tree, then\n> I resolve/merge from tree A to tree B, compile B\n> and run it.\n> \n> If I want to run project C and project B with your\n> latest tree, I resolve/merge from tree A to tree B\n> and from tree B to tree C, compile C and run it.\n\nNo.\n\nIf tree B is based on _some_point_in_ A, then you just test that.\n\nBecause development line B is _independent_ of development line A. The \nfact that A changes doesn't change B - unless they have some real \ndependencies (which we should try to avoid).\n\nSo when you update (\"fetch\" in git parlance) branch A from me, that \nshouldn't affect branch B _nor_ branch C in any way. They clearly do not \ndepend on the new stuff in A, since they do their own independent \ndevelopment. The fact that they _started_ at some random point during the \ndevelopment of A doesn't change that fact.\n\nNow, if you want to _test_ the combined \"new stuff in branch A and new \nstuff in branch B\", feel free to do that. But realize that that is _not_ \nappropriate in either branch A _nor_ branch B.\n\nSo you'd be much better off with a separate \"test\" branch that you test \nstuff out in, and you then resolve (\"pull\" in git parlance) both branch A \nand branch B into that test branch.\n\nSee? Testing the combination of two branches doesn't actually have \nanything to do with either branch.\n\nAt some point, you decide that you want to merge what you've done in \nbranch B. That's a _different_ and independent thing from deciding that \nyou want to test the combination of two development branches. Clearly, \nit's great to test often, but that has nothing to do with releasing a \nbranch.\n\n> In such cases, are you saying that you'd prefer to\n> pull from Tree B and Tree C (depending on your needs)?\n\nI'm saying that mixing up the \"let's test the combination\" and \"let's \nmerge the two branches\" are totally different things and should not be \nmixed up.\n\nOne is a random event (and then it makes sense to have, for example, a \n\"automated test branch\" that automatically merges every day and tests the \nresults. I don't think you should expose those random merges to others, \nbecause they actually hinder the readability of the history for _both_ \nsides.\n\nThe other is a _directed_ event. It's the event of saying \"branch B\" is \nnow ready to be merged. Usually that's best done by just saying \"please \npull now\" - ie not by merging branch A into branch B (because that's not \nwhat you actually want, is it? What you want is for the development in \nbranch B to show up in branch A - so you want branch A to do the pull).\n\nNow, there's a third kind of event, which is again independent of the \nother two. It's more of a \"let's try to keep the 'topic branch' \ndevelopment up-to-date with the branch we eventually want to merge the \ntopic changes into\". That's where you can now do two things:\n\n - David often \"rebases\" all of the changes in his \"topic branch\" (ie \n conceptually \"branch B\") to the new top-of-head of \"branch A\". In other \n words, he re-writes branch B entirely _as_if_ it was based on the newer \n state \"branch A\". This is what \"git rebase\" is all about.\n\n - You can just pull from branch A into branch B, as a way to keep branch \n B more up-to-date with the work in the \"main trunk\" or whatever. This \n is ok, but it shouldn't be a common event. It should be something that \n happens when you (for example) notice during testing that the test \n merge no longer works cleanly. Or it might be \"It's now been two weeks \n since I synchronized, let's just synchronize to be safe\".\n\nSee? I'm not objecting to topic branches pulling from my tree in general. \nIt's just that they should have a _reason_. There's never any reason to \npull into a development tree that you haven't done any development in, \njust because you also want to use that development tree for testing.\n\n> Another question:\n> Sometimes, a fix for project B finds its way into\n> tree C (project C) (since C depended on that fix in B).\n> Now I'd like to pull that particular fix, identified by\n> its SHA, into project B, and nothing else, for this I can\n> use git-cherry-pick, right?\n\nThat's one way. It's often the best way, especially if it's a really \nobvious bugfix. Or you could just fix it in your tree yourself. It will \nmean that the two branches have the same fix, but especially if it really \nis an identical fix, it won't be a merge problem.\n\nYou _can_ just decide to pull branch B into branch C, but that has a real \nproblem, namely that it inexorably links the two together, so that nobody \ncan then pull branch C without pulling indirectly branch B at the time \nthat B->C merge happened. Sometimes that is ok. But it's nice to avoid it \nif you can.\n\nBut for example, if somebody fixed something in the trunk, and you \nactually do need that fix from the trunk for your topic branch \ndevelopment, then just doing a pull is _fine_. Now we're back to doing a \nmerge that actually has a perfectly good reason.\n\nIOW, don't cherry-pick to avoid merges when the merge really does make \ntons of sense. Merges are good, it's just that _too_ much of a good thing \nis bad.\n\n> And lastly, is there a tool whereby I can \"see\" changes\n> between repos, kind of like git-diff but being able to\n> give URLs too?\n\nNo, all the good tools really are based on fetching (NOT \"pulling\") the \nother branch into your local tree as a separate branch. At that point, \nthere are tons of wonderful tools you can use.\n\nIn other words, say that you want to know what has happened in another \nrepository, at git://git.kernel.org/xyzzy. You aren't interested in the \nstuff that is already part of the trunk, you're just interested in what is \nonly in that \"xyzzy\" branch, and how it relates to your code. \n\nWhat you'd do is\n\n\tgit fetch git://git.kernel.org/xyzzy master:xyzzy-snapshot\n\nwhich says \"fetch the 'master' branch from that xyzzy repository, and call \nit 'xyzzy-snapshot' locally.\n\nYou can then (for example) fetch the code that is in _my_ tree by doign \nthe same time (just call that branch 'linus'), and you can now do\n\n\tgitk linus..xyzzy-snapshot HEAD\n\nwhich looks strange (you give \"gitk\" _both_ a range from the \"linus\" \nbranch to the \"xyzzy-snapshot\" _and_ your own HEAD at this time), but what \nit basically does is that the \"linus..\" syntax tells git that you're not \ninterested in anything that is already in the 'linus' branch.\n\nSo the above command line will actually graphically show _both_ your \ncurrent HEAD branch _and_ the 'xyzzy-snapshot' branch, in parallel. You \ncan see how (if at all) they are related to each other, ignoring all the \ncommits that have already made it into my tree.\n\n(You can also do \"linus..HEAD\" instead of just HEAD and effectively repeat \nthe \"don't show 'linus' branch any more\" twice. It's perfectly equivalent, \nof course. You may also want to use the \"-d\" flag to \"gitk\" which tells it \nto show things in date order, instead of a simplified history order).\n\nOr just do \"what has xyzzy-snapshot that I do not have in my HEAD\":\n\n\tgit log HEAD..xyzzy-snapshot\n\n(or gitk), or the other way around: what do _I_ have in my HEAD that \nhasn't been pushed to xyzzy-snapshot yet:\n\n\tgit log xyzzy-snapshot..HEAD\n\n(or do diffs, \"git whatchanged -p\", or whatever).\n\nIn other words, using a few different branches (you can make them up \ndynamically) can be very powerful.\n\n\t\tLinus\n"},{"id":"14335","messageId":"Pine.LNX.4.64.0601081909250.3169@g5.osdl.org","threadId":"3009","inReplyTo":"20060108230611.GP3774-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds-3nddppzayc0@public.gmane.org","sentAt":"2006-01-09T03:26:50Z","receivedAt":"2006-01-09T03:26:50Z","isPatch":false,"sender":{"key":"torvalds-3nddppzayc0@public.gmane.org","avatar":null},"body":"\n\nOn Mon, 9 Jan 2006, Adrian Bunk wrote:\n> \n> Consider I want to do the following:\n> 1. update my tree daily from your tree\n> 2. include 10 patches per week into my tree\n> 3. ask you once a month to pull from my tree\n> \n> How should step 1 be done?\n\nI'd do\n\n\tgit fetch linus\n\nto fetch my tree as a branch (obviously, this assumes you've set up a \n'.git/remotes/linus' file for the shorthand).\n\nThen, keep your checked-out working-tree that you also do you development \nin your 'devel' branch (or whatever).\n\nAnd then do\n\n\tgit-rebase linus\n\nto rebase your development branch to mine.\n\nTHIS is what \"rebase\" is for. It sounds like what you really want to do is \nnot have a development branch at all, but you just want to track my tree \nand then keep track of a few branches of your own. In other words, you \ndon't really have a \"real\" branch - you've got an odd collection of \npatches that you really want to carry around on top of _my_ branch. No?\n\nNow, in this model, you're not really using git as a distributed system. \nIn this model, you're using git to track somebody elses tree, and track a \nfew patches on top of it, and then \"git rebase\" is a way to move the base \nthat you're tracking your patches against forwards..\n\nIt's also entirely possible that you may want to look at \"stacked git\" \n(stg), which is really more about a \"quilt on top of git\" approach. Which \nagain, may or may not suit your needs better.\n\nNow, the other alternative is to use git as a \"real\" distributed system, \nand then you might keep my \"linus\" branch around perhaps as a reference \npoint, but you don't care too much about it. What you care a lot more \nabout is your \"real development\" branch, and you simply don't rebase that, \nor try to track my branch all that closely. You work in your real \ndevelopment branch, and that's your bread and butter. You _don't_ merge my \ntree every day, because you simply don't care - that's a separate issue.\n\nYou might have a totally different directory that you use _just_ to track \nmy tree, and that is my virgin tree checked out and ready to go to test \nwhat _I_ am doing - totally independently of your tree.\n\nSee? Two totally different usage schenarios. In one, you keep a couple of \n\"odd-ball\" patches around (hey, it could be many, but I say a couple just \nbecause the patches aren't a huge deal - they are kind of a small side \nproject to you, and not the main focus). And you use \"git rebase\" to move \nthose patches forward to match the \"real\" tree, aka mine.\n\nIn the other schenario, your development tree is a full-fledged real \nbranch, with a life of its own, and _not_ slaved to what happens to be \ngoing on in my tree. You may care about my tree for _other_ reasons, but \nthe two aren't really joined at the hip.\n\nThe third schenario is somewhere in between: you do pull from my tree, but \nyou do it occasionally enough that the merges don't get annoying.\n\nMost people I work with are actually in that gray area. EVERYBODY pulls \nsome. Nobody tends to do black-and-white either-or schenario. The question \nis just how much. \n\nMy gut rule: if you have almost as many merges as you have \"real work\" \ncommits, you're doing something bad, and you should pull less often \n(perhaps by using \"rebase\", perhaps by just realizing that you don't need \nto be tailgating _quite_ that closely).\n\nBut 30 \"real\" commits and 5 merges because the 30 real commits happened \nover four weeks time? Sounds fine to me. \n\n\t\tLinus\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14337","messageId":"46a038f90601082034g2865b26ftc344c599e29a4655@mail.gmail.com","threadId":"3009","inReplyTo":"Pine.LNX.4.64.0601081909250.3169-hNm40g4Ew95AfugRpC6u6w@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Martin Langhoff","fromEmail":"martin.langhoff-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2006-01-09T04:34:25Z","receivedAt":"2006-01-09T04:34:25Z","isPatch":false,"sender":{"key":"martin.langhoff-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"On 1/9/06, Linus Torvalds wrote:\n> And then do\n>\n> git-rebase linus\n>\n> to rebase your development branch to mine.\n>\n> THIS is what \"rebase\" is for. It sounds like what you really want to do is\n> not have a development branch at all, but you just want to track my tree\n> and then keep track of a few branches of your own. In other words, you\n> don't really have a \"real\" branch - you've got an odd collection of\n> patches that you really want to carry around on top of _my_ branch. No?\n\nFWIW, I determine whether I should rebase or merge based on\n\n + Whether the branch/head I maintain is public. For public repos, I\n*must* merge carefully as rebase \"rewinds\" the head and that makes a\nmess of any repositor tracking me.\n\n + Whether the changes on my both sides are significant, and it is\nsemantically meaningful to have a merge. If either side had just a\ncouple of minor commits, rebase makes life a lot easier down the path.\nIf both side clearly saw parallel development, it is more sincere to\nmerge and let that be recorded.\n\n + If my attempt to rebase leads to any non-trivial conflicts or\nco-dependencies, then I definitely cancel the rebase and merge.\n\n> Now, in this model, you're not really using git as a distributed system.\n\nI'd argue that it is not about distributed or not. It's all in what\nyou want to record in your history. As such, it is a communication\ndevice -- and I want to make effective use of it. I guess the question\nI ask myself is: what will communicate what's happened here most\nclearly? What will be useful for people to read? In that context, a\nwhite-lie here and there simplifying the history a bit where it's not\ninteresting counts as a good thing.\n\ncheers,\n\n\nmartin\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14433","messageId":"20060110201909.GB3911@stusta.de","threadId":"3009","inReplyTo":"Pine.LNX.4.64.0601081909250.3169@g5.osdl.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Adrian Bunk","fromEmail":"bunk@stusta.de","sentAt":"2006-01-10T20:19:09Z","receivedAt":"2006-01-10T20:19:09Z","isPatch":false,"sender":{"key":"bunk@stusta.de","avatar":null},"body":"On Sun, Jan 08, 2006 at 07:26:50PM -0800, Linus Torvalds wrote:\n>...\n> THIS is what \"rebase\" is for. It sounds like what you really want to do is \n> not have a development branch at all, but you just want to track my tree \n> and then keep track of a few branches of your own. In other words, you \n> don't really have a \"real\" branch - you've got an odd collection of \n> patches that you really want to carry around on top of _my_ branch. No?\n\nYes.\n\n> Now, in this model, you're not really using git as a distributed system. \n> In this model, you're using git to track somebody elses tree, and track a \n> few patches on top of it, and then \"git rebase\" is a way to move the base \n> that you're tracking your patches against forwards..\n\nI am using the workaround of carrying the patches in a mail folder, \napplying them in a batch, and not pulling from your tree between \napplying a batch of patches and you pulling from my tree.\n\n> It's also entirely possible that you may want to look at \"stacked git\"\n> (stg), which is really more about a \"quilt on top of git\" approach. Which\n> again, may or may not suit your needs better.\n>...\n\nAfter a quick look, stg seems to be an interesting project that might \nsuit my needs.\n\nI'd say the main problem is that git with several other projects like \ncogito and stg on top of it allow many different workflows. But finding \nthe one that suits one's needs without doing something in a wrong way\nis non-trivial.\n\nIt might help if someone could write some kind of \"Git for dummies\" that \nfocusses only on the usage and advantages/disadvantages of user \ninterfaces like cogito, stg and (H)GCT and restricts the discussion of \ngit internals to a short paragraph in the introduction.\n\n> \t\tLinus\n\ncu\nAdrian\n\n-- \n\n \"Is there not promise of rain?\" Ling Tan asked suddenly out\n of the darkness. There had been need of rain for many days.\n \"Only a promise,\" Lao Er said.\n Pearl S. Buck - Dragon Seed\n"},{"id":"14439","messageId":"Pine.LNX.4.64.0601101229390.4939@g5.osdl.org","threadId":"3009","inReplyTo":"20060110201909.GB3911-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds-3nddppzayc0@public.gmane.org","sentAt":"2006-01-10T20:31:18Z","receivedAt":"2006-01-10T20:31:18Z","isPatch":false,"sender":{"key":"torvalds-3nddppzayc0@public.gmane.org","avatar":null},"body":"\n\nOn Tue, 10 Jan 2006, Adrian Bunk wrote:\n> \n> > Now, in this model, you're not really using git as a distributed system. \n> > In this model, you're using git to track somebody elses tree, and track a \n> > few patches on top of it, and then \"git rebase\" is a way to move the base \n> > that you're tracking your patches against forwards..\n> \n> I am using the workaround of carrying the patches in a mail folder, \n> applying them in a batch, and not pulling from your tree between \n> applying a batch of patches and you pulling from my tree.\n\nYes, that also works.\n\nI think \"quilt\" is really the right thing here, although stg may be even \neasier due to the more direct git integration. But with a smallish number \nof patches, just doing patch management by hand is obviously simply not a \nhuge problem either, so extra tools may just end up confusing the issue.\n\n\t\tLinus\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14438","messageId":"46a038f90601101233h5def4840k315be9520796b5e@mail.gmail.com","threadId":"3009","inReplyTo":"20060110201909.GB3911@stusta.de","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-10T20:33:11Z","receivedAt":"2006-01-10T20:33:11Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/11/06, Adrian Bunk wrote:\n> I am using the workaround of carrying the patches in a mail folder,\n> applying them in a batch, and not pulling from your tree between\n> applying a batch of patches and you pulling from my tree.\n\nIn that case, there's a mostly automated way of doing that if you read\nthe last couple lines of git-rebase, using something along the lines\nof\n\n git-format-patch | git-am -3 -k\n\n> I'd say the main problem is that git with several other projects like\n> cogito and stg on top of it allow many different workflows. But finding\n> the one that suits one's needs without doing something in a wrong way\n> is non-trivial.\n\nYou are right about that, but much of the space (of what workflows are\ninteresting) is still being explored, and git and the porcelains\nreacting to people's interests. So it's still a moving target. A fast\nmoving target.\n\ncheers,\n\n\nmartin\n"},{"id":"14455","messageId":"43C450CF.8070102@op5.se","threadId":"3009","inReplyTo":"46a038f90601101233h5def4840k315be9520796b5e@mail.gmail.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-11T00:26:55Z","receivedAt":"2006-01-11T00:26:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Martin Langhoff wrote:\n> On 1/11/06, Adrian Bunk wrote:\n> \n>>I am using the workaround of carrying the patches in a mail folder,\n>>applying them in a batch, and not pulling from your tree between\n>>applying a batch of patches and you pulling from my tree.\n> \n> \n> In that case, there's a mostly automated way of doing that if you read\n> the last couple lines of git-rebase, using something along the lines\n> of\n> \n> git-format-patch | git-am -3 -k\n> \n\nIsn't this rebase in a nutshell ?\n\n> \n>>I'd say the main problem is that git with several other projects like\n>>cogito and stg on top of it allow many different workflows. But finding\n>>the one that suits one's needs without doing something in a wrong way\n>>is non-trivial.\n> \n> \n> You are right about that, but much of the space (of what workflows are\n> interesting) is still being explored, and git and the porcelains\n> reacting to people's interests. So it's still a moving target. A fast\n> moving target.\n> \n\nGood thing there are competent people around to snipe those targets in \nmid-stride. :)\n\nI for one was amazed at how much easier git was to work with than any of \nthe other scm's I've tried (quite a few, I never really liked any of \nthem), and I really like the fact that it's flexible enough to suit \n(almost) all our needs. The only thing I haven't really found it to be \nsatisfactory for is our collection of RPM spec-files and their \nrespective patches, where we not so much change files as continuously \nreplace them completely. Perhaps that's changed now that most \ngit-commands can be run from subdirs.\n\nSo, kudos to Linus for inventing it, Junio for nursing it, and the other \n129 developers that have so far contributed to the current release.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"14554","messageId":"20060112013706.GA3339@kroah.com","threadId":"3009","inReplyTo":"20060110201909.GB3911@stusta.de","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2006-01-12T01:37:06Z","receivedAt":"2006-01-12T01:37:06Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Tue, Jan 10, 2006 at 09:19:09PM +0100, Adrian Bunk wrote:\n> \n> I am using the workaround of carrying the patches in a mail folder, \n> applying them in a batch, and not pulling from your tree between \n> applying a batch of patches and you pulling from my tree.\n\nIck, I'd strongly recommend using quilt for this. It works great for\njust this kind of workflow.\n\nthanks,\n\ngreg k-h\n"},{"id":"14555","messageId":"tnxirspo29g.fsf@arm.com","threadId":"3009","inReplyTo":"20060112013706.GA3339-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Catalin Marinas","fromEmail":"catalin.marinas-5wv7dgnigg8@public.gmane.org","sentAt":"2006-01-12T16:10:51Z","receivedAt":"2006-01-12T16:10:51Z","isPatch":false,"sender":{"key":"catalin.marinas-5wv7dgnigg8@public.gmane.org","avatar":null},"body":"Greg KH wrote:\n> On Tue, Jan 10, 2006 at 09:19:09PM +0100, Adrian Bunk wrote:\n>> \n>> I am using the workaround of carrying the patches in a mail folder, \n>> applying them in a batch, and not pulling from your tree between \n>> applying a batch of patches and you pulling from my tree.\n>\n> Ick, I'd strongly recommend using quilt for this. It works great for\n> just this kind of workflow.\n\nOr StGIT :-). Similar workflow (and similar commands) but better\nintegrated with GIT and better at dealing with conflicts since it uses\na three-way merge when pushing patches rather than applying them with\n\"patch\".\n\n-- \nCatalin\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14613","messageId":"20060113145027.GN29663@stusta.de","threadId":"3009","inReplyTo":"20060112013706.GA3339@kroah.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Adrian Bunk","fromEmail":"bunk@stusta.de","sentAt":"2006-01-13T14:50:27Z","receivedAt":"2006-01-13T14:50:27Z","isPatch":false,"sender":{"key":"bunk@stusta.de","avatar":null},"body":"On Wed, Jan 11, 2006 at 05:37:06PM -0800, Greg KH wrote:\n> On Tue, Jan 10, 2006 at 09:19:09PM +0100, Adrian Bunk wrote:\n> > \n> > I am using the workaround of carrying the patches in a mail folder, \n> > applying them in a batch, and not pulling from your tree between \n> > applying a batch of patches and you pulling from my tree.\n> \n> Ick, I'd strongly recommend using quilt for this. It works great for\n> just this kind of workflow.\n\nIt works in my case because I'm only going through the folder with the \ntrivial patches in batches and ask Linus to pull from my tree \nimmediately after I'm finished.\n\nThat would certainly not be a recommended practice for a subsystem \nmaintainer, but I'm handling only trivial patches.\n\n> thanks,\n> \n> greg k-h\n\ncu\nAdrian\n\n-- \n\n \"Is there not promise of rain?\" Ling Tan asked suddenly out\n of the darkness. There had been need of rain for many days.\n \"Only a promise,\" Lao Er said.\n Pearl S. Buck - Dragon Seed\n"}]}