{"thread":{"id":"325","subject":"Re: : Networking","startedAt":"2005-04-26T07:57:25Z","lastAt":"2005-04-28T04:43:58Z","messageCount":13,"participants":["Andrew Morton","Linus Torvalds","Daniel Barkalow","Jan Harkes","Petr Baudis","Bram Cohen","Ryan Anderson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1724","messageId":"20050426005725.6bfe6135.akpm@osdl.org","threadId":"325","inReplyTo":"20050425214326.512b006e.davem@davemloft.net","subject":"Re: : Networking","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2005-04-26T07:57:25Z","receivedAt":"2005-04-26T07:57:25Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"\"David S. Miller\" <davem@davemloft.net> wrote:\n>\n> Linus, please pull from:\n> \n>  \trsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git\n\nSo I tried to apply my new get-mm-patches-from-git methodology on this and\ncame unstuck.\n\n-mm kernels consist of a series of patches against the most recent release\n(2.6.12-rc3 today):\n\n\tlinus.patch\t\t(Linus' changes since 2.6.12-rc3)\n\tgit-net.patch\t\t(Davem's changes wrt Linus's latest tree)\n\tetc...\n\nThe algorithm is:\n\n\na) Set up the git repo\n\n\tmkdir git26\n\tgit init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\n\t(Futz around in `git log' output to identify the v2.6.12-rc3 commit, do\n\t `git tag v2.6.12-rc3 a2755a80f40e5794ddc20e00f781af9d6320fafb')\n\nb) Add davem's repo:\n\n\tgit addremote git-net rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git\n\nc) To generate -mm's linus.patch (patch against 2.6.12-rc3):\n\n\tgit pull origin\n\tgit diff -r v2.6.12-rc3 > ../25/patches/linus.patch\n\nd) To generate davem's tree (patch against linus's current tree (ie: patch\n   against 2.6.12-rc3+linus.patch)):\n\n\tgit pull git-net\n\tMERGE_BASE=$(merge-base $(cat .git/heads/origin ) $(cat .git/heads/git-net))\n\tgit diff -r $MERGE_BASE:$(cat .git/heads/git-net) > ../25/patches/git-net.patch\n\ne) Repeat d) for all known git trees.\n\n\n\nBut git-net.patch has a bunch of bluetooth stuff in it which is already in\nLinus's tree.  And git-net.patch modifies net/sched/simple.c, which doesn't\nappear in either 2.6.12-rc3 or in current -linus.\n\n\nDoing step d) by hand:\n\n\n\tbix:/usr/src/git26> cat .git/heads/origin\n\tb453257f057b834fdf9f4a6ad6133598b79bd982\n\tbix:/usr/src/git26> cat .git/heads/git-net\n\t5523662c4cd585b892811d7bb3e25d9a787e19b3\n\tbix:/usr/src/git26> merge-base b453257f057b834fdf9f4a6ad6133598b79bd982 5523662c4cd585b892811d7bb3e25d9a787e19b3\n\t25ee7e3832951cf5896b194f6cd929a44863f419\n\n\tbix:/usr/src/git26> cat-file commit 25ee7e3832951cf5896b194f6cd929a44863f419\n\ttree 5b6486ded5188e41ac9bc81ad4a5e2bd746f7ede\n\tparent 056de2fa12febe02597f971eb6ea8f2cc9c9b06e\n\tauthor Adrian Bunk <bunk@stusta.de> 1114442294 -0700\n\tcommitter Linus Torvalds <torvalds@ppc970.osdl.org> 1114442294 -0700\n\n\t[PATCH] fs/aio.c: make some code static\n\n\tThis patch makes some needlessly global code static.\n\n\tSigned-off-by: Adrian Bunk <bunk@stusta.de>\n\tAcked-by: Benjamin LaHaise <bcrl@kvack.org>\n\tSigned-off-by: Linus Torvalds <torvalds@osdl.org>\n\n\nThat seems to be a reasonable gca.  It's the last thing which Linus added\nprior to merging the ARM patches, which presumably weren't in Dave's tree.\n\nSo let's try to grab davem's diff wrt that gca:\n\nbix:/usr/src/git26> git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:5523662c4cd585b892811d7bb3e25d9a787e19b3 | diffstat\n drivers/net/tg3.c                            |   73 ++++++++++++++-------------\n net/bluetooth/af_bluetooth.c                 |    1 \n net/bluetooth/bnep/sock.c                    |    1 \n net/bluetooth/cmtp/capi.c                    |    1 \n net/bluetooth/cmtp/core.c                    |    1 \n net/bluetooth/cmtp/sock.c                    |    1 \n net/bluetooth/hci_conn.c                     |    1 \n net/bluetooth/hci_core.c                     |    1 \n net/bluetooth/hci_event.c                    |    1 \n net/bluetooth/hci_sock.c                     |    1 \n net/bluetooth/hidp/core.c                    |    1 \n net/bluetooth/hidp/sock.c                    |    1 \n net/bluetooth/l2cap.c                        |    1 \n net/bluetooth/rfcomm/sock.c                  |    1 \n net/bluetooth/sco.c                          |    1 \n net/core/rtnetlink.c                         |    1 \n net/core/scm.c                               |    1 \n net/core/sock.c                              |    1 \n net/ipv4/af_inet.c                           |    1 \n net/ipv4/ip_output.c                         |    2 \n net/ipv4/netfilter/ip_conntrack_ftp.c        |    4 -\n net/ipv4/netfilter/ip_conntrack_standalone.c |    7 --\n net/ipv4/tcp_input.c                         |    1 \n net/ipv6/af_inet6.c                          |    1 \n net/netlink/af_netlink.c                     |    1 \n net/sched/simple.c                           |   18 ------\n net/unix/af_unix.c                           |    1 \n 27 files changed, 46 insertions(+), 80 deletions(-)\n\nAnd that's the bad patch.\n\nWhat did I do wrong?\n\nCan someone suggest a better approach?\n\nThanks.\n\n"},{"id":"1739","messageId":"Pine.LNX.4.58.0504260746320.18901@ppc970.osdl.org","threadId":"325","inReplyTo":"20050426005725.6bfe6135.akpm@osdl.org","subject":"Re: : Networking","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T14:59:30Z","receivedAt":"2005-04-26T14:59:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Andrew Morton wrote:\n> \n> So I tried to apply my new get-mm-patches-from-git methodology on this and\n> came unstuck.\n\nYes. You cannot just apply patches, since that will inevitably fail if \nthere is any overlap. Which there quite often is.\n\nFor this to work in general, you really have to merge the different git \ntrees, and generate patches from _that_.\n\n> a) Set up the git repo\n> \n> \tmkdir git26\n> \tgit init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\nYes. In the long run, you really should need to do this just once, since \nif there is one thing git should be good at, it's just keeping tons of \nrandom collections of objects around.\n\nThe only thing you should be a bit careful about is to remember what the \n\"heads\" at different points were. In particular, you want to remember \nwhere you merged with me last was. I've started tagging my releases with \nthe git tag facility (_not_ the pasky one, but I think pasky will start \npicking up on that soon enough), so finding a specific release will be \neasy, but if you ever do a non-release merge you'll just have to tag it \nyourself.\n\n> b) Add davem's repo:\n> \n> \tgit addremote git-net rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git\n> \n> c) To generate -mm's linus.patch (patch against 2.6.12-rc3):\n> \n> \tgit pull origin\n> \tgit diff -r v2.6.12-rc3 > ../25/patches/linus.patch\n\nYou should now also remember the HEAD at this point. That's your \"base\" \nfor any future patches, since you expect other patches to apply on top of \nthat.\n\nI think cogito remembers it in the \"origin\" thing, but you should check.\n\nSave it away in (for example) .git/last-diff-head:\n\n\tcat .git/HEAD > .git/last-diff-head\n\n> d) To generate davem's tree (patch against linus's current tree (ie: patch\n>    against 2.6.12-rc3+linus.patch)):\n> \n> \tgit pull git-net\n\nYes. This should have merged the two (assuming \"git pull\" does what I \nthink it does).\n\n> \tMERGE_BASE=$(merge-base $(cat .git/heads/origin ) $(cat .git/heads/git-net))\n> \tgit diff -r $MERGE_BASE:$(cat .git/heads/git-net) > ../25/patches/git-net.patch\n\nNo. Now you ended up looking at the last common ancestor of the thing you \nmerged, and you _should_ have looked at what the difference was _before_ \nthe merge. \n\nSo assuming it does remember it in \"origin\", you should just have done\n\n\tgit diff -r $(cat .git/last-diff-head):$(cat .git/HEAD)\n\nwhich basically says \"diff between the tree at the time of my last diff,\nand the result of the merge\".\n\nThen you just update your last-diff-head to reflect that:\n\n\tcat .git/HEAD > .git/last-diff-head\n\nand you go on:\n\n> e) Repeat d) for all known git trees.\n\nYup.\n\n\t\t\t\tLinus\n"},{"id":"1743","messageId":"Pine.LNX.4.21.0504261114090.30848-100000@iabervon.org","threadId":"325","inReplyTo":"Pine.LNX.4.58.0504260746320.18901@ppc970.osdl.org","subject":"Re: : Networking","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-26T15:40:08Z","receivedAt":"2005-04-26T15:40:08Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 26 Apr 2005, Linus Torvalds wrote:\n\n> On Tue, 26 Apr 2005, Andrew Morton wrote:\n> > \n> \n> The only thing you should be a bit careful about is to remember what the \n> \"heads\" at different points were. In particular, you want to remember \n> where you merged with me last was. I've started tagging my releases with \n> the git tag facility (_not_ the pasky one, but I think pasky will start \n> picking up on that soon enough), so finding a specific release will be \n> easy, but if you ever do a non-release merge you'll just have to tag it \n> yourself.\n\nYour tag system is in the \"cogito-0.8\" release, plus a pasky-style way of\nkeeping track of what tags you have in your repository.\n\n> > d) To generate davem's tree (patch against linus's current tree (ie: patch\n> >    against 2.6.12-rc3+linus.patch)):\n> > \n> > \tgit pull git-net\n> \n> Yes. This should have merged the two (assuming \"git pull\" does what I \n> think it does).\n\nI think git pull only downloads the contents of the repo and saves the new\nhead in a separate file. You're left to do the merge yourself, in case\nwhat you actually wanted to do was just read the patches in the remote\nrepo without merging them.\n\nYou probably need a \"git merge git-net\" here, and things will be in the\nstate that Linus expects.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"1754","messageId":"20050426171938.GA7632@delft.aura.cs.cmu.edu","threadId":"325","inReplyTo":"20050426005725.6bfe6135.akpm@osdl.org","subject":"Re: : Networking","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2005-04-26T17:19:38Z","receivedAt":"2005-04-26T17:19:38Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"Forgot to cc: git@vger when I sent this originally.\n\nOn Tue, Apr 26, 2005 at 12:57:25AM -0700, Andrew Morton wrote:\n>  27 files changed, 46 insertions(+), 80 deletions(-)\n> \n> And that's the bad patch.\n\nBoth Linus and DaveM merged the same patch from Al Viro, but they are\nofcourse different commits. So both branches have diverged and would\nneed to be merged, where someone decides if Linus's commit or Dave's\ncommit should be used.\n\n> What did I do wrong?\n> \n> Can someone suggest a better approach?\n\nWell, I looked at the history, and if I skip the Viro patch in davem's\nbranch by hand I get,\n\n$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:088dd3a45fdb8fb726cd50575856562c4f6f1c3e | diffstat \n drivers/net/tg3.c                            |   73 ++++++++++++++-------------\n net/ipv4/ip_output.c                         |    2 \n net/ipv4/netfilter/ip_conntrack_ftp.c        |    4 -\n net/ipv4/netfilter/ip_conntrack_standalone.c |    7 --\n net/ipv4/tcp_input.c                         |    1 \n net/sched/simple.c                           |   18 ------\n 6 files changed, 46 insertions(+), 59 deletions(-)\n\nSo now, how to do this without picking through the logs. I figured the\npatchutils stuff might have a solution for this. So I got the diffs on\nLinus's branch wrt to the gca, and from Dave's branch wrt to the gca.\n\n$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:b453257f057b834fdf9f4a6ad6133598b79bd982 > git-linus.patch\n$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:5523662c4cd585b892811d7bb3e25d9a787e19b3 > git-net.patch\n$ interdiff --no-revert-omitted -p1 git-linus.patch git-net.patch | diffstat\n drivers/net/tg3.c                            |   73 ++++++++++++++-------------\n net/ipv4/ip_output.c                         |    2\n net/ipv4/netfilter/ip_conntrack_ftp.c        |    4 -\n net/ipv4/netfilter/ip_conntrack_standalone.c |    7 --\n net/ipv4/tcp_input.c                         |    1 \n net/sched/simple.c                           |   18 ------\n 6 files changed, 46 insertions(+), 59 deletions(-)\n\nThat looks like it matched.\n\nJan\n"},{"id":"1763","messageId":"20050426181554.GA13224@pasky.ji.cz","threadId":"325","inReplyTo":"Pine.LNX.4.21.0504261114090.30848-100000@iabervon.org","subject":"Re: : Networking","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-26T18:15:54Z","receivedAt":"2005-04-26T18:15:54Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 26, 2005 at 05:40:08PM CEST, I got a letter\nwhere Daniel Barkalow <barkalow@iabervon.org> told me that...\n> On Tue, 26 Apr 2005, Linus Torvalds wrote:\n> \n> > On Tue, 26 Apr 2005, Andrew Morton wrote:\n> > > \n> > \n> > The only thing you should be a bit careful about is to remember what the \n> > \"heads\" at different points were. In particular, you want to remember \n> > where you merged with me last was. I've started tagging my releases with \n> > the git tag facility (_not_ the pasky one, but I think pasky will start \n> > picking up on that soon enough), so finding a specific release will be \n> > easy, but if you ever do a non-release merge you'll just have to tag it \n> > yourself.\n> \n> Your tag system is in the \"cogito-0.8\" release, plus a pasky-style way of\n> keeping track of what tags you have in your repository.\n\nIt came in with merge with Linus, but there's no support in the Cogito\ntoolkit for it whatsoever.\n\nI'm personally unlikely to get any time for doing it (or much anything\nelse; but this is probably the priority now) until Sunday evening. :-(\n\n> > > d) To generate davem's tree (patch against linus's current tree (ie: patch\n> > >    against 2.6.12-rc3+linus.patch)):\n> > > \n> > > \tgit pull git-net\n> > \n> > Yes. This should have merged the two (assuming \"git pull\" does what I \n> > think it does).\n> \n> I think git pull only downloads the contents of the repo and saves the new\n> head in a separate file. You're left to do the merge yourself, in case\n> what you actually wanted to do was just read the patches in the remote\n> repo without merging them.\n> \n> You probably need a \"git merge git-net\" here, and things will be in the\n> state that Linus expects.\n\nYes. git pull only pulls the stuff, doesn't merge it (that is, unless it\nis tracked branch; but I think this isn't the case; this was cleaned up\nin cogito-0.8 and cg-pull now always only pulls, cg-update\npulls+merges).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1768","messageId":"20050426183350.GB13224@pasky.ji.cz","threadId":"325","inReplyTo":"20050426005725.6bfe6135.akpm@osdl.org","subject":"Re: : Networking","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-26T18:33:50Z","receivedAt":"2005-04-26T18:33:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 26, 2005 at 09:57:25AM CEST, I got a letter\nwhere Andrew Morton <akpm@osdl.org> told me that...\n> c) To generate -mm's linus.patch (patch against 2.6.12-rc3):\n> \n> \tgit pull origin\n> \tgit diff -r v2.6.12-rc3 > ../25/patches/linus.patch\n\n(Mainly for people not familiar with git-pasky - this merged origin to\nthe working tree since it was tracked branch - that's what origin is by\ndefault after git init.)\n\n> d) To generate davem's tree (patch against linus's current tree (ie: patch\n>    against 2.6.12-rc3+linus.patch)):\n> \n> \tgit pull git-net\n> \tMERGE_BASE=$(merge-base $(cat .git/heads/origin ) $(cat .git/heads/git-net))\n> \tgit diff -r $MERGE_BASE:$(cat .git/heads/git-net) > ../25/patches/git-net.patch\n\nThis is the bad way; I think this suffers of basically the same problems\nas my ancient merging by \"forward-patching\". You should probably do a\nregular merge:\n\n\tgit pull git-net\n\tgit merge git-net\n\tgit diff -p\n\nThe last command will show diff between current tree and the first\nparent; that amounts the merged patch in this case.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1772","messageId":"20050426115609.0481401b.akpm@osdl.org","threadId":"325","inReplyTo":"20050426183350.GB13224@pasky.ji.cz","subject":"Re: : Networking","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2005-04-26T18:56:09Z","receivedAt":"2005-04-26T18:56:09Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Petr Baudis <pasky@ucw.cz> wrote:\n>\n>  > d) To generate davem's tree (patch against linus's current tree (ie: patch\n>  >    against 2.6.12-rc3+linus.patch)):\n>  > \n>  > \tgit pull git-net\n>  > \tMERGE_BASE=$(merge-base $(cat .git/heads/origin ) $(cat .git/heads/git-net))\n>  > \tgit diff -r $MERGE_BASE:$(cat .git/heads/git-net) > ../25/patches/git-net.patch\n> \n>  This is the bad way; I think this suffers of basically the same problems\n>  as my ancient merging by \"forward-patching\". You should probably do a\n>  regular merge:\n> \n>  \tgit pull git-net\n>  \tgit merge git-net\n>  \tgit diff -p\n> \n>  The last command will show diff between current tree and the first\n>  parent; that amounts the merged patch in this case.\n\nBear in mind that there will be 20 or 30 different trees which I'll need\nthe diffs for, not just the one git-net.\n\nI don't know if it'll be successful continually merging all those trees\ntogether.  The way I did this with bk was to have a separate repo for each\ntree, but I don't think I'll want 30-40 separate git trees.\n\nMy little methodology worked nicely for git-ia64.\n\nJan Harkes has pointed out that the problem here is that Linus and Dave\nboth applied the same patch from Al and that interdiff was able to fix it\nup:\n\n$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:b453257f057b834fdf9f4a6ad6133598b79bd982 > git-linus.patch\n$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:5523662c4cd585b892811d7bb3e25d9a787e19b3 > git-net.patch\n$ interdiff --no-revert-omitted -p1 git-linus.patch git-net.patch | diffstat\ndrivers/net/tg3.c                            |   73 ++++++++++++++-------------\nnet/ipv4/ip_output.c                         |    2\nnet/ipv4/netfilter/ip_conntrack_ftp.c        |    4 -\nnet/ipv4/netfilter/ip_conntrack_standalone.c |    7 --\nnet/ipv4/tcp_input.c                         |    1 \nnet/sched/simple.c                           |   18 ------\n6 files changed, 46 insertions(+), 59 deletions(-)\n\nSo hm.  I guess git did what it was supposed to do here, and that a `git\nmerge' would have removed the common patch.  But if I take the approach of\nmerging all those subsystem trees I do wonder if things will come\nunstuck...\n"},{"id":"1777","messageId":"Pine.LNX.4.58.0504261209470.18901@ppc970.osdl.org","threadId":"325","inReplyTo":"20050426115609.0481401b.akpm@osdl.org","subject":"Re: : Networking","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T19:13:06Z","receivedAt":"2005-04-26T19:13:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Andrew Morton wrote:\n> \n> I don't know if it'll be successful continually merging all those trees\n> together.  The way I did this with bk was to have a separate repo for each\n> tree, but I don't think I'll want 30-40 separate git trees.\n\nYou really don't. With git, the only thing you need is one object store,\nand some way to _track_ those 30-40 separate git trees (and \"track\" really\nmeans \"remember a single SHA1 name for their top-of-tree\").\n\nThen you can merge any combination of the 40 in the same tree. \n\nYou'll get confused easily, but if you do this all with tools, it \nshouldn't be too bad.\n\n> So hm.  I guess git did what it was supposed to do here, and that a `git\n> merge' would have removed the common patch.  But if I take the approach of\n> merging all those subsystem trees I do wonder if things will come\n> unstuck...\n\nWell, git isn't as good at merging as BK is, and your usage sure as hell\nwould be a horrible worst-case example, but it might actually work fine.  \nGit merges are _cheap_ (with a capital C, and probably H as well) when\nthey work out, and quite frankly, so far they have always worked out for\nme.\n\nBut yeah, you'd be doing some pretty aggressive merging, using a tool that \nis two weeks old. It might work. I'd be interested to know ;)\n\n\t\tLinus\n"},{"id":"1779","messageId":"20050426125141.6ec38d31.akpm@osdl.org","threadId":"325","inReplyTo":"Pine.LNX.4.58.0504261209470.18901@ppc970.osdl.org","subject":"Re: : Networking","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2005-04-26T19:51:41Z","receivedAt":"2005-04-26T19:51:41Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Linus Torvalds <torvalds@osdl.org> wrote:\n>\n> \n> \n> On Tue, 26 Apr 2005, Andrew Morton wrote:\n> > \n> > I don't know if it'll be successful continually merging all those trees\n> > together.  The way I did this with bk was to have a separate repo for each\n> > tree, but I don't think I'll want 30-40 separate git trees.\n> \n> You really don't. With git, the only thing you need is one object store,\n> and some way to _track_ those 30-40 separate git trees (and \"track\" really\n> means \"remember a single SHA1 name for their top-of-tree\").\n\nPetr's wrappers do all that head tracking OK (which is why I'm using a\ncombo of those and of lower-level gittiness).  They do handy remote repo\ntracking too.\n\n> Then you can merge any combination of the 40 in the same tree. \n> \n> You'll get confused easily, but if you do this all with tools, it \n> shouldn't be too bad.\n> \n> > So hm.  I guess git did what it was supposed to do here, and that a `git\n> > merge' would have removed the common patch.  But if I take the approach of\n> > merging all those subsystem trees I do wonder if things will come\n> > unstuck...\n> \n> Well, git isn't as good at merging as BK is, and your usage sure as hell\n> would be a horrible worst-case example, but it might actually work fine.  \n> Git merges are _cheap_ (with a capital C, and probably H as well) when\n> they work out, and quite frankly, so far they have always worked out for\n> me.\n> \n> But yeah, you'd be doing some pretty aggressive merging, using a tool that \n> is two weeks old. It might work. I'd be interested to know ;)\n\nHm.  For now I might try what I have plus Jan's fancy interdiff command to\nremove duped patches.  We'll see.  I obtained a copy of Tony's ia64 diff\nquite happily - it didn't have any duplicates.\n\n(It's fairly common for two subsystem maintainers to apply the same patch. \nWith bk I was resolving that by just smashing the patches on top of each\nother, ignoring the rejects and refreshing the topmost patch.  That\napproach actually resolved this linus-vs-davem dupe as well.  But the duped\npatch was so damn BIG that it threw me.  And I wasn't feeling gitty enough\nto go hunting about looking for the particular patch(es) which caused the\nproblem)\n"},{"id":"1783","messageId":"Pine.LNX.4.58.0504261310120.18901@ppc970.osdl.org","threadId":"325","inReplyTo":"20050426125141.6ec38d31.akpm@osdl.org","subject":"Re: : Networking","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T20:11:26Z","receivedAt":"2005-04-26T20:11:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Andrew Morton wrote:\n>\n> With bk I was resolving that by just smashing the patches on top of each\n> other, ignoring the rejects and refreshing the topmost patch.  That\n> approach actually resolved this linus-vs-davem dupe as well. \n\nOh, wow. I didn't realize that your scripts were quite _that_ stupid, and \ndidn't actually take advantage of any automatic merges at all.\n\nIf so, git should trivially do everything that BK ever did for you. Which \nis not saying a lot ;)\n\n\t\tLinus\n"},{"id":"1792","messageId":"Pine.LNX.4.44.0504261332540.4678-100000@wax.eds.org","threadId":"325","inReplyTo":"Pine.LNX.4.58.0504261310120.18901@ppc970.osdl.org","subject":"Re: : Networking","fromName":"Bram Cohen","fromEmail":"bram@bitconjurer.org","sentAt":"2005-04-26T20:35:55Z","receivedAt":"2005-04-26T20:35:55Z","isPatch":false,"sender":{"key":"bram@bitconjurer.org","avatar":null},"body":"Linus Torvalds wrote:\n\n> On Tue, 26 Apr 2005, Andrew Morton wrote:\n> >\n> > With bk I was resolving that by just smashing the patches on top of each\n> > other, ignoring the rejects and refreshing the topmost patch.  That\n> > approach actually resolved this linus-vs-davem dupe as well.\n>\n> Oh, wow. I didn't realize that your scripts were quite _that_ stupid, and\n> didn't actually take advantage of any automatic merges at all.\n>\n> If so, git should trivially do everything that BK ever did for you. Which\n> is not saying a lot ;)\n\nNo version control system will do a particularly good job of merging\ncontent which got passed around outside of the system. They can be made to\nsort-of handle some simple cases well, but fundamentally too much\ninformation is getting dropped.\n\nThe solution is to get everyone using the same version control system,\nwhich is actually quite a workable solution if (a) the version control\nsystem in question is quite nice, and (b) there isn't some deep political\nreason why many people will never agree to use it.\n\n-Bram\n\n"},{"id":"1986","messageId":"20050428035534.GB30308@mythryan2.michonline.com","threadId":"325","inReplyTo":"Pine.LNX.4.44.0504261332540.4678-100000@wax.eds.org","subject":"Re: : Networking","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-04-28T03:55:34Z","receivedAt":"2005-04-28T03:55:34Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Tue, Apr 26, 2005 at 01:35:55PM -0700, Bram Cohen wrote:\n> Linus Torvalds wrote:\n> \n> > On Tue, 26 Apr 2005, Andrew Morton wrote:\n> > >\n> > > With bk I was resolving that by just smashing the patches on top of each\n> > > other, ignoring the rejects and refreshing the topmost patch.  That\n> > > approach actually resolved this linus-vs-davem dupe as well.\n> >\n> > Oh, wow. I didn't realize that your scripts were quite _that_ stupid, and\n> > didn't actually take advantage of any automatic merges at all.\n> >\n> > If so, git should trivially do everything that BK ever did for you. Which\n> > is not saying a lot ;)\n> \n> No version control system will do a particularly good job of merging\n> content which got passed around outside of the system. They can be made to\n> sort-of handle some simple cases well, but fundamentally too much\n> information is getting dropped.\n\nOne thing to keep in mind, about the way Linux development works (and\nhonestly, the way I think \"git\" development is currently working) is\nthat one of the things the version control system has to provide an easy\nmethod to do is to abandon history that is messy.\n\nFor example, I'm adding a new driver, \"foobar\".\n\nIt uses the fancy quantum-bus, which is fairly new to the kernel.\nThe bus driver is new, and I go off, work in my private tree for a\nmonth, fixing all kinds of quantum-entanglement related bugs, and\ncommitting as I go.\n\nI get everything working, and submit my driver.\n\nThe quantum-bus maintainer replies and says, \"Hey, I reworked the API so\nthat you don't need to worry about all this quantum-entanglement stuff\nanymore, just call compensate_for_heisenberg() before doing the DMA.\"\n\nI swear for a day or two, and rework my driver, and resubmit it.\n\nNow, all that history I had, with the duplicated imlementation, and\nuseless code is in my tree.\n\nThe current (as I understand it) policy is, \"We don't want that\nhistory.\"  This means that the developer will build a new tree (maybe),\nexport his patch and reimport it into a clean tree, making a much\nsimpler history graph.\n\nWhat Andrew is doing isn't too far from this, in concept, it's just a\nlot more complicated because he's pulling something insane, like 27\nseperate trees, plus several hundred stand alone patches.\n\nSo, there's a *deliberate* desire to drop history and move some content\naround outside of version control.\n\nNow, the desire to pull a bunch of seperate trees, merge them, produce a\ndiff that roughly pertains to what came in from each tree, and collect\nthat as a patch series may be strange, but it seems to be working really\nwell at the moment, for Linux development.\n\n> The solution is to get everyone using the same version control system,\n> which is actually quite a workable solution if (a) the version control\n> system in question is quite nice, and (b) there isn't some deep political\n> reason why many people will never agree to use it.\n\nGit (well, cogito, really) seems to be getting there awfully fast - I'm\nrather impressed with the speed of it, and annoyed that I haven't had\nthe time to build up a test suite for merging!\n\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"1990","messageId":"Pine.LNX.4.21.0504280031110.30848-100000@iabervon.org","threadId":"325","inReplyTo":"20050428035534.GB30308@mythryan2.michonline.com","subject":"Re: : Networking","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-28T04:43:58Z","receivedAt":"2005-04-28T04:43:58Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 27 Apr 2005, Ryan Anderson wrote:\n\n> Now, all that history I had, with the duplicated imlementation, and\n> useless code is in my tree.\n> \n> The current (as I understand it) policy is, \"We don't want that\n> history.\"  This means that the developer will build a new tree (maybe),\n> export his patch and reimport it into a clean tree, making a much\n> simpler history graph.\n\nI've been doing just this. I actually import it in pieces, with a commit\nbetween each, so it's just like I applied the patch series I'm about to\nsend out. It actually works beautifully, and, someday, I'll have the\nseries up on my site so that a maintainer can just pull it.\n\nHonestly, I'm not interested long-term in my buggy history, even\nlocally; I'm interested in the clean history in which I make a series of\nself-contained, logical modifications and they get merged upstream.\n\n> What Andrew is doing isn't too far from this, in concept, it's just a\n> lot more complicated because he's pulling something insane, like 27\n> seperate trees, plus several hundred stand alone patches.\n> \n> So, there's a *deliberate* desire to drop history and move some content\n> around outside of version control.\n\nI think it's more a desire to drop history as it actually happened, and\nreplace it with history as it should have happened. The one thing I would\nlike is the ability to provide merging help to poor souls who got part of\nthe messy history without preserving that history. I think having the head\nof the clean series have a bunch of lines: \"replaces <sha1>\", where people\naren't supposed to have or want that commit, but if they've merged it,\nthey should know that the clean series includes its content.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"}]}