{"thread":{"id":"4810","subject":"RFH: refactor read-tree","startedAt":"2006-07-08T22:28:00Z","lastAt":"2006-07-09T22:17:53Z","messageCount":7,"participants":["Johannes Schindelin","Linus Torvalds","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23444","messageId":"Pine.LNX.4.63.0607090015250.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4810","inReplyTo":null,"subject":"RFH: refactor read-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-08T22:28:00Z","receivedAt":"2006-07-08T22:28:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nthe last thing to do with merge-recursive to speed it up, would be to \navoid reading/writing the cache all the time.\n\nUnfortunately, builtin-read-tree.c grew into a pretty big monster, with so \nmany different options which completely change behaviour.\n\nSo, how should I go about it? Should I make a struct a la diff_options to \nhold the options to unpack_trees? Where should it go?\n\nI also played a little with git-merge-tree, because it seems so much \nsimpler and easier to refactor. But there is a problem: Either I call it \nthe wrong way, or it does not yet work correctly: I tried\n\n\tgit-merge-tree $(git-merge-base branch1 branch2) branch1 branch2\n\nwith what is in 'next'. But it only showed the _new_ files, not the \nmodified ones.\n\nHelp, please?\n\nCiao,\nDscho\n"},{"id":"23447","messageId":"Pine.LNX.4.64.0607082011060.5623@g5.osdl.org","threadId":"4810","inReplyTo":"Pine.LNX.4.63.0607090015250.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFH: refactor read-tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-09T03:15:41Z","receivedAt":"2006-07-09T03:15:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 9 Jul 2006, Johannes Schindelin wrote:\n> \n> I also played a little with git-merge-tree, because it seems so much \n> simpler and easier to refactor. But there is a problem: Either I call it \n> the wrong way, or it does not yet work correctly: I tried\n> \n> \tgit-merge-tree $(git-merge-base branch1 branch2) branch1 branch2\n> \n> with what is in 'next'. But it only showed the _new_ files, not the \n> modified ones.\n\nWhat git-merge-tree does is to show the _difference_ to \"branch1\".\n\nSo if the result of the merge would be totally identical to \"branch1\", \nthen git-merge-tree should be totally silent.\n\nThe basic idea is that \"branch1\" should be your current branch, and it \nobviously is also expected to match (more or less) the current index. So \nyou can do a merge by\n\n - reading in \"branch1\" into the index:\n\n\tGIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1\n\n - doing a \"git-merge-tree $base $branch1 $branch2\"\n\n - using the _result_ of \"git-merge-tree\" to modify the index you just \n   read in.\n\n - write out the end result as the result of the merge.\n\nAnd yes, I agree 100% that \"git-read-tree\" has become an unholy mess. I \nlooked at it, and I think it's unfixable. I considered re-writing it from \nscratch, at least for some specific cases, but I couldn't bring myself to \ndo it.\n\n\t\t\tLinus\n"},{"id":"23476","messageId":"20060709124324.GE5919@steel.home","threadId":"4810","inReplyTo":"Pine.LNX.4.64.0607082011060.5623@g5.osdl.org","subject":"Re: RFH: refactor read-tree","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-09T12:43:24Z","receivedAt":"2006-07-09T12:43:24Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:\n> The basic idea is that \"branch1\" should be your current branch, and it \n> obviously is also expected to match (more or less) the current index. So \n> you can do a merge by\n> \n>  - reading in \"branch1\" into the index:\n> \n> \tGIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1\n\nwhat is \"-m\" here for?\n"},{"id":"23479","messageId":"Pine.LNX.4.63.0607091630110.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4810","inReplyTo":"20060709124324.GE5919@steel.home","subject":"Re: RFH: refactor read-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-09T14:30:44Z","receivedAt":"2006-07-09T14:30:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 9 Jul 2006, Alex Riesen wrote:\n\n> Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:\n> > The basic idea is that \"branch1\" should be your current branch, and it \n> > obviously is also expected to match (more or less) the current index. So \n> > you can do a merge by\n> > \n> >  - reading in \"branch1\" into the index:\n> > \n> > \tGIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1\n> \n> what is \"-m\" here for?\n\nIt means that git-read-tree tries to merge the current index with branch1.\n\nCiao,\nDscho\n"},{"id":"23483","messageId":"Pine.LNX.4.63.0607091650030.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4810","inReplyTo":"Pine.LNX.4.64.0607082011060.5623@g5.osdl.org","subject":"Re: RFH: refactor read-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-09T14:55:04Z","receivedAt":"2006-07-09T14:55:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 8 Jul 2006, Linus Torvalds wrote:\n\n> On Sun, 9 Jul 2006, Johannes Schindelin wrote:\n> > \n> > I also played a little with git-merge-tree, because it seems so much \n> > simpler and easier to refactor. But there is a problem: Either I call it \n> > the wrong way, or it does not yet work correctly: I tried\n> > \n> > \tgit-merge-tree $(git-merge-base branch1 branch2) branch1 branch2\n> > \n> > with what is in 'next'. But it only showed the _new_ files, not the \n> > modified ones.\n> \n> What git-merge-tree does is to show the _difference_ to \"branch1\".\n\nI see my problem: branch1 is not the \"upstream\" branch, but my own. Tsk. \nToo easy.\n\nNow, if only merge-tree knew about renames. *sigh*.\n\n> And yes, I agree 100% that \"git-read-tree\" has become an unholy mess. I \n> looked at it, and I think it's unfixable. I considered re-writing it from \n> scratch, at least for some specific cases, but I couldn't bring myself to \n> do it.\n\nWell, I think that at least the unpack_tree() thing should be relatively \neasy to extract. And the rest _should_ be relatively easy to clean up, \nprovided we introduce a read_tree_options struct, which gets passed around \na la \"this\" in Java/C++.\n\nCiao,\nDscho\n"},{"id":"23485","messageId":"Pine.LNX.4.64.0607090827430.5623@g5.osdl.org","threadId":"4810","inReplyTo":"Pine.LNX.4.63.0607091630110.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: RFH: refactor read-tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-09T15:30:26Z","receivedAt":"2006-07-09T15:30:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 9 Jul 2006, Johannes Schindelin wrote:\n> \n> On Sun, 9 Jul 2006, Alex Riesen wrote:\n> \n> > Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:\n> > > The basic idea is that \"branch1\" should be your current branch, and it \n> > > obviously is also expected to match (more or less) the current index. So \n> > > you can do a merge by\n> > > \n> > >  - reading in \"branch1\" into the index:\n> > > \n> > > \tGIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1\n> > \n> > what is \"-m\" here for?\n> \n> It means that git-read-tree tries to merge the current index with branch1.\n\nWell, the current index always \"merges\" by just taking the timestamps from \nit. The actual _content_ doesn't matter for the single-tree case.\n\nFor the two- and three-tree case, \"git-read-tree -m\" will verify that the \nparts that got changed still _match_ in the index, but for a single-tree \n\"git-read-tree\", there's nothing to match against, just the target, so \nthe only thing it does is that for matching index/target-tree entries it \nwill re-use the index timestamps (and other stat info).\n\n\t\t\tLinus\n"},{"id":"23498","messageId":"20060709221753.GB6966@steel.home","threadId":"4810","inReplyTo":"Pine.LNX.4.64.0607090827430.5623@g5.osdl.org","subject":"Re: RFH: refactor read-tree","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-09T22:17:53Z","receivedAt":"2006-07-09T22:17:53Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Sun, Jul 09, 2006 17:30:26 +0200:\n> > > > The basic idea is that \"branch1\" should be your current branch, and it \n> > > > obviously is also expected to match (more or less) the current index. So \n> > > > you can do a merge by\n> > > > \n> > > >  - reading in \"branch1\" into the index:\n> > > > \n> > > > \tGIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1\n> > > \n> > > what is \"-m\" here for?\n> > \n> > It means that git-read-tree tries to merge the current index with branch1.\n> \n> Well, the current index always \"merges\" by just taking the timestamps from \n> it. The actual _content_ doesn't matter for the single-tree case.\n\nBut the name suggests it's a temporary index, which would not have\nanything in it and even the .git/tmp-index is not supposed to exist.\nSo I'd actually understand this as creating an index from the tree-ish\nbranch1, without merging anything. And continue wondering what that -m\nis for...\n"}]}