{"thread":{"id":"358","subject":"RE: git pull on ia64 linux tree","startedAt":"2005-04-27T22:11:38Z","lastAt":"2005-04-28T01:24:34Z","messageCount":11,"participants":["Luck, Tony","Linus Torvalds","Petr Baudis","Edgar Toernig"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1917","messageId":"B8E391BBE9FE384DAA4C5C003888BE6F035B31D9@scsmsx401.amr.corp.intel.com","threadId":"358","inReplyTo":null,"subject":"RE: git pull on ia64 linux tree","fromName":"Luck, Tony","fromEmail":"tony.luck@intel.com","sentAt":"2005-04-27T22:11:38Z","receivedAt":"2005-04-27T22:11:38Z","isPatch":false,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":">On Wed, 27 Apr 2005 tony.luck@intel.com wrote:\n>> \n>> please pull from:\n>> \n>> \t\n>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git\n>\n>Merged and pushed out. You should probably check the end \n>result, but it all looks good from here.\n\nThe merge is right ... but \"cg-update\" leaves files that have been\ndeleted lying around in the checked out tree.\n\n-Tony\n"},{"id":"1921","messageId":"Pine.LNX.4.58.0504271525520.18901@ppc970.osdl.org","threadId":"358","inReplyTo":"B8E391BBE9FE384DAA4C5C003888BE6F035B31D9@scsmsx401.amr.corp.intel.com","subject":"RE: git pull on ia64 linux tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-27T22:35:07Z","receivedAt":"2005-04-27T22:35:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Apr 2005, Luck, Tony wrote:\n> \n> The merge is right ... but \"cg-update\" leaves files that have been\n> deleted lying around in the checked out tree.\n\nYes. I _think_ the right thing to do ends up being something like the \nupdate script doing\n\n\tdiff-tree -r $orig $final | grep '^-'\n\nat the end to get the list of deleted files, and just doing 'rm' on the \nresult.\n\nOne problem with this is that \"grep\" always thinks lines end in '\\n', and \nwhat we'd really want (from a scriptability angle) is\n\n\tdiff-tree -z -r $orig $final | grep -0 '^-'\n\nbut I don't think you can tell grep to think that lines are\nzero-terminated instead of terminated with \\n'. But I don't see how to do\nthat with grep.\n\nAnother similar alternative is to use \"show-files --others\" before and\nafter the merge and seeing what files got added to the list of \"files we\ndon't track\", but that just sounds horribly hacky.\n\nAnyway, there are clearly at least two ways of doing this, and we'll just\nhave to have people work on the scripts to do it right..\n\n\t\tLinus\n"},{"id":"1926","messageId":"20050427225821.GI22956@pasky.ji.cz","threadId":"358","inReplyTo":"Pine.LNX.4.58.0504271525520.18901@ppc970.osdl.org","subject":"Re: git pull on ia64 linux tree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-27T22:58:21Z","receivedAt":"2005-04-27T22:58:21Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 28, 2005 at 12:35:07AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> One problem with this is that \"grep\" always thinks lines end in '\\n', and \n> what we'd really want (from a scriptability angle) is\n> \n> \tdiff-tree -z -r $orig $final | grep -0 '^-'\n> \n> but I don't think you can tell grep to think that lines are\n> zero-terminated instead of terminated with \\n'. But I don't see how to do\n> that with grep.\n\nActually, grep has -z parameter. ;-)\n\nFixed and pushed out.\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":"1931","messageId":"Pine.LNX.4.58.0504271618540.18901@ppc970.osdl.org","threadId":"358","inReplyTo":"20050427225821.GI22956@pasky.ji.cz","subject":"Re: git pull on ia64 linux tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-27T23:19:53Z","receivedAt":"2005-04-27T23:19:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Petr Baudis wrote:\n> \n> Actually, grep has -z parameter. ;-)\n\nAhh. It's not even mentioned in the grep man-page (which mentions -Z, but \nthat's for grep _output_, not input).\n\n\t\tLinus\n"},{"id":"1936","messageId":"Pine.LNX.4.58.0504271632060.18901@ppc970.osdl.org","threadId":"358","inReplyTo":"20050427225821.GI22956@pasky.ji.cz","subject":"Re: git pull on ia64 linux tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-27T23:36:19Z","receivedAt":"2005-04-27T23:36:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Petr Baudis wrote:\n> \n> Fixed and pushed out.\n\nIt looks like you only did the fix for the pure \"just update to the \nversion at the other end\" case. \n\nSo if you actually end up doing a merge, it still leaves all the old files\n(that the merge may have removed from the tree) around. Or did I miss \nsomething?\n\n\t\tLinus\n"},{"id":"1942","messageId":"20050428000729.GT22956@pasky.ji.cz","threadId":"358","inReplyTo":"Pine.LNX.4.58.0504271632060.18901@ppc970.osdl.org","subject":"Re: git pull on ia64 linux tree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-28T00:07:29Z","receivedAt":"2005-04-28T00:07:29Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 28, 2005 at 01:36:19AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> \n> \n> On Thu, 28 Apr 2005, Petr Baudis wrote:\n> > \n> > Fixed and pushed out.\n> \n> It looks like you only did the fix for the pure \"just update to the \n> version at the other end\" case. \n> \n> So if you actually end up doing a merge, it still leaves all the old files\n> (that the merge may have removed from the tree) around. Or did I miss \n> something?\n\nHmm, doesn't the three-way read-tree -m take care of that? Then it\nshould hit\n\n\t#\n\t# deleted in one and unchanged in the other\n\t#\n\t\"$1.$1\" | \"$1$1.\")\n\t\t#echo \"Removing $4\"\n\t\trm -f -- \"$4\"; update-cache --remove -- \"$4\"\n\t\texit 0\n\t\t;;\n\nin cg-Xmergefile.\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":"1945","messageId":"Pine.LNX.4.58.0504271719380.18901@ppc970.osdl.org","threadId":"358","inReplyTo":"20050428000729.GT22956@pasky.ji.cz","subject":"Re: git pull on ia64 linux tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T00:21:19Z","receivedAt":"2005-04-28T00:21:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Petr Baudis wrote:\n> \n> Hmm, doesn't the three-way read-tree -m take care of that? Then it\n> should hit\n\nYes, you're right, I didn't think about the fact that the helper script \nactually does the checkout for the clashing files it merges.\n\n(Which is not really nice, because it means that some files get updated \nand others don't, depending on how they were merged, but whatever..)\n\n\t\t\tLinus\n"},{"id":"1948","messageId":"20050428003342.GW22956@pasky.ji.cz","threadId":"358","inReplyTo":"Pine.LNX.4.58.0504271719380.18901@ppc970.osdl.org","subject":"Re: git pull on ia64 linux tree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-28T00:33:43Z","receivedAt":"2005-04-28T00:33:43Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 28, 2005 at 02:21:19AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> \n> \n> On Thu, 28 Apr 2005, Petr Baudis wrote:\n> > \n> > Hmm, doesn't the three-way read-tree -m take care of that? Then it\n> > should hit\n> \n> Yes, you're right, I didn't think about the fact that the helper script \n> actually does the checkout for the clashing files it merges.\n> \n> (Which is not really nice, because it means that some files get updated \n> and others don't, depending on how they were merged, but whatever..)\n\nWe always do checkout-cache -f -a after we do merge-cache, so it should\nend up in a consistent state.\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":"1960","messageId":"Pine.LNX.4.58.0504271805550.18901@ppc970.osdl.org","threadId":"358","inReplyTo":"20050428003342.GW22956@pasky.ji.cz","subject":"Re: git pull on ia64 linux tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T01:08:29Z","receivedAt":"2005-04-28T01:08:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Petr Baudis wrote:\n>\n> > (Which is not really nice, because it means that some files get updated \n> > and others don't, depending on how they were merged, but whatever..)\n> \n> We always do checkout-cache -f -a after we do merge-cache, so it should\n> end up in a consistent state.\n\nI agree that for the common case it doesn't really matter, since we'll \nalways update the working directory regardless.\n\nIt was more of a conceptual complaint. We do everything else purely in the\nindex, so it's a bit confusing that in that intermediate stage _some_\nfiles end up being up-to-date, and others end up not.\n\n\t\tLinus\n"},{"id":"1961","messageId":"20050428031302.50fbe006.froese@gmx.de","threadId":"358","inReplyTo":"Pine.LNX.4.58.0504271525520.18901@ppc970.osdl.org","subject":"Re: git pull on ia64 linux tree","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2005-04-28T01:13:02Z","receivedAt":"2005-04-28T01:13:02Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"Linus Torvalds wrote:\n> \n> One problem with this is that \"grep\" always thinks lines end in '\\n', and \n> what we'd really want (from a scriptability angle) is\n> \n> \tdiff-tree -z -r $orig $final | grep -0 '^-'\n\nDon't you think it's much easier to reject filenames with control\nchars?  Forget all this -z/-0 stuff.  It only complicates life and\nsupporting filenames with embedded newlines is useless in practice.\n\n--- x/update-cache.c Thu Apr 21 19:58:47 2005\n+++ y/update-cache.c Thu Apr 28 02:55:27 2005\n@@ -227,7 +227,8 @@\n  * are hidden, for chist sake.\n  *\n  * Also, we don't want double slashes or slashes at the\n- * end that can make pathnames ambiguous.\n+ * end that can make pathnames ambiguous nor any control\n+ * chars.\n  */\n static int verify_path(char *path)\n {\n@@ -237,6 +238,8 @@\n \tfor (;;) {\n \t\tif (!c)\n \t\t\treturn 1;\n+\t\tif ((unsigned char)c < 32)\n+\t\t\treturn 0;\n \t\tif (c == '/') {\n inside:\n \t\tc = *path++;\n\n\nCiao, ET.\n"},{"id":"1965","messageId":"20050428012434.GC3422@pasky.ji.cz","threadId":"358","inReplyTo":"Pine.LNX.4.58.0504271805550.18901@ppc970.osdl.org","subject":"Re: git pull on ia64 linux tree","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-28T01:24:34Z","receivedAt":"2005-04-28T01:24:34Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 28, 2005 at 03:08:29AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> \n> \n> On Thu, 28 Apr 2005, Petr Baudis wrote:\n> >\n> > > (Which is not really nice, because it means that some files get updated \n> > > and others don't, depending on how they were merged, but whatever..)\n> > \n> > We always do checkout-cache -f -a after we do merge-cache, so it should\n> > end up in a consistent state.\n> \n> I agree that for the common case it doesn't really matter, since we'll \n> always update the working directory regardless.\n> \n> It was more of a conceptual complaint. We do everything else purely in the\n> index, so it's a bit confusing that in that intermediate stage _some_\n> files end up being up-to-date, and others end up not.\n\nThis actually came all the way from git-merge-one-file-script.\n\nI don't think the intermediate stage matters at all, actually; from the\nuser's point of view it is nearly instantenous, and the tree keeps\nchanging during the merge anyway, when you are trying to resolve\nnon-exact merges by the merge utility. From the user's point of view,\nthe act of merging is atomic and you always end up with something\nconsistent, unless cg-merge is killed. But in that case it's all messed\nup anyway and you'll better just cg-cancel and try again.\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"}]}