{"thread":{"id":"3698","subject":"Errors GITtifying GCC and Binutils","startedAt":"2006-03-22T13:33:37Z","lastAt":"2006-03-26T02:52:31Z","messageCount":43,"participants":["Jan-Benedict Glaw","Linus Torvalds","H. Peter Anvin","Keith Packard","sean","Shawn Pearce","Ryan Anderson","David S. Miller","Timo Hirvonen","Junio C Hamano","Chris Shoemaker","Mark Wooding","Andreas Ericsson","Ralf Baechle","Johannes Schindelin","Carl Worth","Santi Béjar","Eric Wong","James Cloos"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17767","messageId":"20060322133337.GU20746@lug-owl.de","threadId":"3698","inReplyTo":null,"subject":"Errors GITtifying GCC and Binutils","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-03-22T13:33:37Z","receivedAt":"2006-03-22T13:33:37Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"Hi!\n\nI'm currently working a lot with Binutils and GCC and wanted to import\nthose two projects into GIT trees, but both of them failed. If anybody\nwants to have access to the half-finished GIT trees, please let me\nknow:\n\nThis is with GIT as of yesterday evening:\n\nBinutils\n~~~~~~~~\n$ /home/jbglaw/bin/git cvsimport -v -d :pserver:anoncvs@sourceware.org:/cvs/src -C src src\n[...]\nUpdate gdb/testsuite/ChangeLog: 230971 bytes\nFetching gdb/testsuite/gdb.base/annota1.exp v 1.1.1.2\nUpdate gdb/testsuite/gdb.base/annota1.exp: 14656 bytes\nFetching gdb/testsuite/gdb.base/annota2.cc v 1.1.1.3\nUpdate gdb/testsuite/gdb.base/annota2.cc: 238 bytes\nFetching gdb/testsuite/gdb.base/annota2.exp v 1.1.1.2\nUpdate gdb/testsuite/gdb.base/annota2.exp: 8639 bytes\nFetching sim/mcore/ChangeLog v 1.1.1.5\nUpdate sim/mcore/ChangeLog: 1325 bytes\nFetching sim/mcore/interp.c v 1.1.1.5\nUpdate sim/mcore/interp.c: 47368 bytes\nTree ID 640f8ff80e14257bc73fa0c3344504c4db960655\nParent ID ac9471abd876476724dc0205272b0565c18b1a7c\nCommitted patch 102 (SNAPSHOT 1999-05-25 18:00:33)\nCommit ID 5847cc095ce0445eb6bf9df1203ccdad35f501fe\nCreated tag 'gdb-1999-05-25' on 'SNAPSHOT'\nSwitching from SNAPSHOT to origin\nFetching bfd/ChangeLog v 1.19\nUpdate bfd/ChangeLog: 118751 bytes\nFetching bfd/elf32-arm.h v 1.4\nUpdate bfd/elf32-arm.h: 90491 bytes\nTree ID 5100b5c49ef78e1027b476f4dbdebeca0b01f113\nParent ID 8d35c43246f8d9693203ef6a87aabf378593bceb\nCommitted patch 103 (origin 1999-05-26 08:27:37)\nCommit ID bb18137d43506ccc7f78da63b18d9f6b6749264d\nFetching include/opcode/ChangeLog v 1.4\nUpdate include/opcode/ChangeLog: 63395 bytes\nFetching include/opcode/hppa.h v 1.2\nUpdate include/opcode/hppa.h: 23271 bytes\nTree ID 7b211af5cb99cbe307d02d72c1e144f3c1aac7e9\nParent ID bb18137d43506ccc7f78da63b18d9f6b6749264d\nCommitted patch 104 (origin 1999-05-26 16:04:10)\nCommit ID 4da3ef4d311fc62a1a0bba8b680595ad824a7e2c\nFetching ld/ChangeLog v 1.11\nUpdate ld/ChangeLog: 328968 bytes\nFetching ld/emulparams/armelf_oabi.sh v 1.2\nUpdate ld/emulparams/armelf_oabi.sh: 585 bytes\nTree ID fcc05a0f9c66693e5b26a5fb4821f6bbeadf4c31\nParent ID 4da3ef4d311fc62a1a0bba8b680595ad824a7e2c\nCommitted patch 105 (origin 1999-05-26 17:23:31)\nCommit ID ddaaceeede7f9bb938188c4f72ddce420d08efad\nSwitching from origin to gdb-4_18-branch\nusage: git-read-tree ( | -m [--aggressive] [-u | -i] [ []])\nread-tree failed: 33024\n\n$ /home/jbglaw/bin/git cvsimport -v -d :pserver:anoncvs@sourceware.org:/cvs/src -C src src\nusage: git-read-tree ( | -m [--aggressive] [-u | -i] [ []])\nread-tree failed: 33024\n\n\n\n\nGCC\n~~~\n$ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc\n[...]\n... 3930 trunk/gcc/combine.c ...\nTree ID 2af6a2f6e28835fec0aaf60d278e356d12d9ae5f\nMerge parent branch: 587bbd00ea5b0f8c18d8ca58bbfcaa4b6b62ff92\nCommitted change 3930:/ 1993-03-30 20:37:29)\nCommit ID 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d\nWriting to refs/heads/origin\nDONE: 3930 origin 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d\n... 3931 trunk/gcc/config/mips/mips.h ...\nTree ID f173f836adf4d8efb42c180d7cd5a786a3acf361\nMerge parent branch: 3ed4cebd349a2c98c7a06d6333b014bd4fe23d6d\nCommitted change 3931:/ 1993-03-30 21:50:50)\nCommit ID 7c132f1464d27bd8198c51913b17a0534376e3e6\nWriting to refs/heads/origin\nDONE: 3931 origin 7c132f1464d27bd8198c51913b17a0534376e3e6\n... 3932 trunk/gcc/config/pa/pa.md ...\nTree ID a88f5523f982dbac1334b78c47fd56a685640a46\nMerge parent branch: 7c132f1464d27bd8198c51913b17a0534376e3e6\nCommitted change 3932:/ 1993-03-30 22:02:05)\nCommit ID 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96\nWriting to refs/heads/origin\nDONE: 3932 origin 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96\n... 3933 trunk/gcc/real.c ...\nTree ID 7d25a64013b301e0e575587a5adfd8b540b4c5a7\nMerge parent branch: 9a8ddfa77f6735c8ba87ab98bc3ac7b056a09d96\nCommitted change 3933:/ 1993-03-31 05:30:24)\nCommit ID 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6\nWriting to refs/heads/origin\nDONE: 3933 origin 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6\n... 3934 trunk/gcc/real.h ...\nTree ID fce52e724f0f1543abd5bd430a11822c3977e803\nMerge parent branch: 70cc7d27f3a4e5117df4e4d2f6e5a2aa4c4a89a6\nCommitted change 3934:/ 1993-03-31 05:39:37)\nCommit ID f8dad6fb5af69122823800ca974e16d4f09906c2\nWriting to refs/heads/origin\nDONE: 3934 origin f8dad6fb5af69122823800ca974e16d4f09906c2\n... 3935 trunk/gcc/Makefile.in ...\nTree ID 7c2cd41d922407ab1df47954fb82964ad7511328\nMerge parent branch: f8dad6fb5af69122823800ca974e16d4f09906c2\nCommitted change 3935:/ 1993-03-31 05:41:37)\nCommit ID eb99aa0ad37564c2071fe4b2f539fe072a72ad4c\nWriting to refs/heads/origin\nDONE: 3935 origin eb99aa0ad37564c2071fe4b2f539fe072a72ad4c\n... 3936 trunk/gcc/c-lex.c ...\nTree ID 90547e4ef900e45f4354aa036f216a3bff93c8dd\nMerge parent branch: eb99aa0ad37564c2071fe4b2f539fe072a72ad4c\nCommitted change 3936:/ 1993-03-31 05:44:03)\nCommit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e\nWriting to refs/heads/origin\nDONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e\n... 3937 trunk/gcc/final.c ...\nCan't fork at /home/jbglaw/bin/git-svnimport line 379.\n\n$ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc\nUse of uninitialized value in system at /home/jbglaw/bin/git-svnimport line 295.\nusage: git-read-tree ( | -m [--aggressive] [-u | -i] [ []])\nread-tree failed: 33024\n\n\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"17786","messageId":"Pine.LNX.4.64.0603221517210.26286@g5.osdl.org","threadId":"3698","inReplyTo":"20060322133337.GU20746@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-22T23:39:00Z","receivedAt":"2006-03-22T23:39:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Mar 2006, Jan-Benedict Glaw wrote:\n> \n> I'm currently working a lot with Binutils and GCC and wanted to import\n> those two projects into GIT trees, but both of them failed. If anybody\n> wants to have access to the half-finished GIT trees, please let me\n> know:\n\nWell, I can re-create your error..\n\n> Switching from origin to gdb-4_18-branch\n> usage: git-read-tree ( | -m [--aggressive] [-u | -i] [ []])\n> read-tree failed: 33024\n\nThat's a horrible error message, and the reason for it is that no \n\"gdb-4_18-branch\" exists.\n\nThere's a _tag_ called \"gdb-4_18\", and there's a branch called \"GDB_4_18\", \nand they actually point to two _different_ commits (both \"Initial creation \nof sourceware repository\"). The commits actually have identical trees, but \nthey're different, because they have different times - by 50 seconds. \n\nGaah.\n\nLooking at cvsps output (from\n\n\tcvsps --norc -u -A -v -d --cvsdirect\n\t\t--root :pserver:anoncvs@sourceware.org:/cvs/src\n\t\tsrc > cvsps.out 2> cvsps.err\n\nit's \"PatchSet 104\" (well, for me it is, I have a hacked cvsps, so it \nmight not be that for you), which creates the \"gdb-4_18-branch\", but it \nappears that cvsps hasn't actually figured out any \"Ancestor branch\" for \nthat commit.\n\nWhat a crock.\n\nAnyway, it's clearly a cvsps bug (mentioning a new branch without the \n_source_ of that branch). Equally clearly, \"git cvsimport\" is being an ass \nabout then failing so totally on it.\n\nI'll try to take a look at why cvsps does that.\n\n\t\tLinus\n"},{"id":"17788","messageId":"Pine.LNX.4.64.0603221607580.26286@g5.osdl.org","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603221517210.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-23T00:12:41Z","receivedAt":"2006-03-23T00:12:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Mar 2006, Linus Torvalds wrote:\n> \n> Looking at cvsps output (from\n> \n> \tcvsps --norc -u -A -v -d --cvsdirect\n> \t\t--root :pserver:anoncvs@sourceware.org:/cvs/src\n> \t\tsrc > cvsps.out 2> cvsps.err\n> \n> it's \"PatchSet 104\" (well, for me it is, I have a hacked cvsps, so it \n> might not be that for you), which creates the \"gdb-4_18-branch\", but it \n> appears that cvsps hasn't actually figured out any \"Ancestor branch\" for \n> that commit.\n\nIt _seems_ that the reason for that is that cvsps considers a revision \nnumber of 1.1.1.1 to have a \"dot depth\" of 0, for some really strange \nreason (it's a total special case).\n\nAnd that will currently not compare as a \"greater\" dot depth than not \nhaving any revision number at all for the ancestor, so such a revision \nwill never be considered an ancestor branch.\n\nThis one-liner to cvsps.c seems to make sure we have an ancestor branch \nfor that \"gdb-4.18-branch\" branch, at least according to the cvsps output. \nI'm re-running \"git cvsimport\" with this cvsps to see if it gets us past \nthat one point, but I need to go pick up Patricia from school, so I won't \nhave time to actually check the result. If somebody wants to play with \nthis, go wild.\n\n(The point of this patch is to make sure that if the head PatchSet doesn't \nhave an ancestor, we'll consider _any_ valid ancestor to be better than \nthat).\n\n\t\tLinus\n\n---\ndiff --git a/cvsps.c b/cvsps.c\n--- a/cvsps.c\n+++ b/cvsps.c\n@@ -2599,7 +2599,7 @@ static void determine_branch_ancestor(Pa\n \t * note: rev is the pre-commit revision, not the post-commit\n \t */\n \tif (!head_ps->ancestor_branch)\n-\t d1 = 0;\n+\t d1 = -1;\n \telse if (strcmp(ps->branch, rev->branch) == 0)\n \t continue;\n \telse if (strcmp(head_ps->ancestor_branch, \"HEAD\") == 0)\n"},{"id":"17794","messageId":"Pine.LNX.4.64.0603221717120.26286@g5.osdl.org","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603221607580.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-23T01:28:23Z","receivedAt":"2006-03-23T01:28:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Mar 2006, Linus Torvalds wrote:\n> \n> This one-liner to cvsps.c seems to make sure we have an ancestor branch \n> for that \"gdb-4.18-branch\" branch, at least according to the cvsps output. \n\nThe \"git cvsimport\" is still running, but at least it seems to be happily \nrunning further past the point it broke earlier.\n\nWill send the patch over to David Mansfield.\n\n\t\tLinus\n"},{"id":"17807","messageId":"44223B90.3040500@zytor.com","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603221607580.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-03-23T06:09:20Z","receivedAt":"2006-03-23T06:09:20Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> It _seems_ that the reason for that is that cvsps considers a revision \n> number of 1.1.1.1 to have a \"dot depth\" of 0, for some really strange \n> reason (it's a total special case).\n> \n\nProbably because in 99% of all cases, revision 1.1.1.1 is the result of \na \"cvs import\".\n\n\t-hpa\n"},{"id":"17811","messageId":"1143128751.6850.35.camel@neko.keithp.com","threadId":"3698","inReplyTo":"44223B90.3040500@zytor.com","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-03-23T15:45:51Z","receivedAt":"2006-03-23T15:45:51Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Wed, 2006-03-22 at 22:09 -0800, H. Peter Anvin wrote:\n> Linus Torvalds wrote:\n> > \n> > It _seems_ that the reason for that is that cvsps considers a revision \n> > number of 1.1.1.1 to have a \"dot depth\" of 0, for some really strange \n> > reason (it's a total special case).\n> > \n> \n> Probably because in 99% of all cases, revision 1.1.1.1 is the result of \n> a \"cvs import\".\n\nAll odd branches are imports. Internal branches are even. So, 1.1.3.1\nwould be the first import along the second vendor branch from the trunk.\n\nNote that vendor branches are always made from the first revision along\na branch, independent of when they occur, so you'll get 1.1.3.1 even if\nthe head revision along the trunk is 1.246.\n\n-- \nkeith.packard@intel.com\n"},{"id":"17812","messageId":"Pine.LNX.4.64.0603230758260.26286@g5.osdl.org","threadId":"3698","inReplyTo":"1143128751.6850.35.camel@neko.keithp.com","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-23T16:01:14Z","receivedAt":"2006-03-23T16:01:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Mar 2006, Keith Packard wrote:\n> \n> Note that vendor branches are always made from the first revision along\n> a branch, independent of when they occur, so you'll get 1.1.3.1 even if\n> the head revision along the trunk is 1.246.\n\nI have to say, that one thing I've learnt during this whole git thing is \nthat other SCM's are DAMN CONFUSED.\n\nI used to think that git was potentially hard to understand. Not so. git \nis an absolute paragon of logic and easy-to-understand concepts.\n\nCompared to SVN (can anybody sat \"trunk/branch/tag confusion\") and CVS, \ngit is not only a hell of a lot more capable, it's just more logical.\n\nWe will hereby start scouring the net for people who say git is hard to \nunderstand and use, and just kill them. They clearly are just polluting \nthe gene pool.\n\n\t\tLinus\n"},{"id":"17816","messageId":"BAYC1-PASMTP0912D2287AB923F3338969AEDE0@CEZ.ICE","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603230758260.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-03-23T18:12:00Z","receivedAt":"2006-03-23T18:12:00Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 23 Mar 2006 08:01:14 -0800 (PST)\nLinus Torvalds wrote:\n\n> I have to say, that one thing I've learnt during this whole git thing is \n> that other SCM's are DAMN CONFUSED.\n> \n> I used to think that git was potentially hard to understand. Not so. git \n> is an absolute paragon of logic and easy-to-understand concepts.\n> \n> Compared to SVN (can anybody sat \"trunk/branch/tag confusion\") and CVS, \n> git is not only a hell of a lot more capable, it's just more logical.\n> \n> We will hereby start scouring the net for people who say git is hard to \n> understand and use, and just kill them. They clearly are just polluting \n> the gene pool.\n\nlol, that sounds like a really good plan. Perhaps as a two pronged effort\nits worth changing the notion that git is primarily \"plumbing\". Adding\nsome of the nice features of cogito and other \"porcelains\" into the core\ngit might go a ways toward converting the few naysayers we don't kill.\n\nSean\n"},{"id":"17818","messageId":"20060323200306.GG31387@lug-owl.de","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603221717120.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-03-23T20:03:06Z","receivedAt":"2006-03-23T20:03:06Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds wrote:\n> On Wed, 22 Mar 2006, Linus Torvalds wrote:\n> > This one-liner to cvsps.c seems to make sure we have an ancestor branch \n> > for that \"gdb-4.18-branch\" branch, at least according to the cvsps output. \n> \n> The \"git cvsimport\" is still running, but at least it seems to be happily \n> running further past the point it broke earlier.\n\nI've started it once again, too, with the one-liner added to Debian\nunstable's version of cvsps:\n\nFetching gas/ChangeLog v 1.479\nUpdate gas/ChangeLog: 250329 bytes\nTree ID a6b48ebac02a4158d37bab17c54c667223ecd971\nParent ID 4cabd2962031fd7ec6416580d84fb30a304969f3\nCommitted patch 3742 (origin 2000-07-29 03:23:31)\nCommit ID 1910c20a44455db916a5c040663716a7389219bc\nFetching winsup/cygwin/fhandler.h v 1.16\nUpdate winsup/cygwin/fhandler.h: 25992 bytes\nFetching winsup/cygwin/include/cygwin/cygwin_dll.h v 1.2\nUpdate winsup/cygwin/include/cygwin/cygwin_dll.h: 3050 bytes\nFetching winsup/cygwin/lib/cygwin_crt0.c v 1.5\nUpdate winsup/cygwin/lib/cygwin_crt0.c: 926 bytes\nTree ID 0c2c7e9d0846e5f42b0bebad8b27ce439ddefb73\nParent ID 1910c20a44455db916a5c040663716a7389219bc\nCommitted patch 3743 (origin 2000-07-29 04:19:24)\nCommit ID a15aac16f12061fbfef1be8f21b80a5076c8d605\nFetching winsup/cygwin/ChangeLog v 1.235\nUpdate winsup/cygwin/ChangeLog: 75391 bytes\nFetching winsup/cygwin/dtable.cc v 1.11\nUpdate winsup/cygwin/dtable.cc: 14399 bytes\nFetching winsup/cygwin/environ.cc v 1.17\nUpdate winsup/cygwin/environ.cc: 17190 bytes\nFetching winsup/cygwin/winsup.h v 1.22\nUpdate winsup/cygwin/winsup.h: 15828 bytes\nTree ID f777977c2b138952bc5a9bc431eec3de99a5f7db\nParent ID a15aac16f12061fbfef1be8f21b80a5076c8d605\nCommitted patch 3744 (origin 2000-07-29 16:01:23)\nCommit ID 38b0ed94ef1c402b7b78ac6cad6c89ce189cd223\nSwitching from origin to #CVSPS_NO_BRANCH\nusage: git-read-tree ( | -m [--aggressive] [-u | -i] [ []])\nread-tree failed: 33024\n\nIt seems there's a patch like\nhttp://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?\n...or we need a better cvsps. Shall I add it and try again / try to\ncontinue, or give up on it for now? Though it would be nice to have\nthese two large and important source trees under GIT control :-)\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"17819","messageId":"Pine.LNX.4.64.0603231134160.26286@g5.osdl.org","threadId":"3698","inReplyTo":"BAYC1-PASMTP0912D2287AB923F3338969AEDE0@CEZ.ICE","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-23T20:38:33Z","receivedAt":"2006-03-23T20:38:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Mar 2006, sean wrote:\n> \n> lol, that sounds like a really good plan. Perhaps as a two pronged effort\n> its worth changing the notion that git is primarily \"plumbing\". Adding\n> some of the nice features of cogito and other \"porcelains\" into the core\n> git might go a ways toward converting the few naysayers we don't kill.\n\nActually, as far as I can tell, git already has a hell of a lot more \nporcelain than pretty much any non-IDE type traditional SCM. Certainly \nmore than CVS.\n\nYeah, I'm not counting things like Eclipse etc. I'm talking about \"plain \nSCM\" environments, ie just basic SVN or CVS. What are we missing in that \ndepartment? (The only thing I can think of is a diff colorizer, which some \nprople seem to really want).\n\n\t\tLinus\n"},{"id":"17820","messageId":"Pine.LNX.4.64.0603231239020.26286@g5.osdl.org","threadId":"3698","inReplyTo":"20060323200306.GG31387@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-23T20:42:20Z","receivedAt":"2006-03-23T20:42:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Mar 2006, Jan-Benedict Glaw wrote:\n>\n> Switching from origin to #CVSPS_NO_BRANCH\n\nAhh. I had some other changes to my cvsps, so I never saw this. I just \nturned the #CVSPS_NO_BRANCH thing into HEAD.\n\n\t\tLinus\n"},{"id":"17822","messageId":"20060323204825.GE30176@spearce.org","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603231134160.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-03-23T20:48:25Z","receivedAt":"2006-03-23T20:48:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Thu, 23 Mar 2006, sean wrote:\n> > \n> > lol, that sounds like a really good plan. Perhaps as a two pronged effort\n> > its worth changing the notion that git is primarily \"plumbing\". Adding\n> > some of the nice features of cogito and other \"porcelains\" into the core\n> > git might go a ways toward converting the few naysayers we don't kill.\n> \n> Actually, as far as I can tell, git already has a hell of a lot more \n> porcelain than pretty much any non-IDE type traditional SCM. Certainly \n> more than CVS.\n> \n> Yeah, I'm not counting things like Eclipse etc. I'm talking about \"plain \n> SCM\" environments, ie just basic SVN or CVS. What are we missing in that \n> department? (The only thing I can think of is a diff colorizer, which some \n> prople seem to really want).\n\nA pretty native point-and-click Windows GUI so Windows users can\nuse GIT without knowing how to actually use their computer. :-)\n\nI'm not trying to bash Windows users. I'm just saying that there's\ndefinately a large user base for SCMs such as CVS who just want\nto check in the latest version of a file they have to maintain.\nMany of these people are afraid of a command prompt. Asking them\nto install Cygwin just to check in a file is a difficult challenge.\n\nAnd even if a user is perfectly comfortable with a command prompt\nand could write one-line scripts faster than anyone else, sometimes\nusers just prefer a GUI interface.\n\nqgit probably comes close in this department but hasn't been packaged\nup into a pretty Windows installer. :-)\n\n\nBut your definately right; once the blame/annotate war settles out\nGIT will have pretty much everything one might need - except a good\ndistributed bug/issue tracking type system. :-)\n\n-- \nShawn.\n"},{"id":"17824","messageId":"20060323210215.GH26071@mythryan2.michonline.com","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603230758260.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-03-23T21:02:15Z","receivedAt":"2006-03-23T21:02:15Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Thu, Mar 23, 2006 at 08:01:14AM -0800, Linus Torvalds wrote:\n> On Thu, 23 Mar 2006, Keith Packard wrote:\n> > \n> > Note that vendor branches are always made from the first revision along\n> > a branch, independent of when they occur, so you'll get 1.1.3.1 even if\n> > the head revision along the trunk is 1.246.\n> \n> I have to say, that one thing I've learnt during this whole git thing is \n> that other SCM's are DAMN CONFUSED.\n> \n> I used to think that git was potentially hard to understand. Not so. git \n> is an absolute paragon of logic and easy-to-understand concepts.\n> \n> Compared to SVN (can anybody sat \"trunk/branch/tag confusion\") and CVS, \n> git is not only a hell of a lot more capable, it's just more logical.\n\nThis might be somewhat controversial, and I haven't done any research to\nconfirm my impression, but you might be just seeing the symptoms of\ndifferent ways of looking at the problem.\n\nScott Collins (QT evangelist, incredibly smart guy) commented to me\nsometime over the summer, that every new SCM was born out of someone's\ndesire to implement a new merge algorithm. While I think that's too\nsimple, I think there have been an awful lot of academic SCMs out there.\n\nGit has taken a very pragmatic approach, in that the goal has been \"What\nis the smallest number of concepts we can create that let us solve the\nproblem, even if we occassionally have to make some tradeoffs?\"\n(Thinking of rename detection there, mostly.)\n\nSo, really, I guess the comment I'm trying to make here is that Occam\nwas right.\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"17825","messageId":"20060323211151.GI26071@mythryan2.michonline.com","threadId":"3698","inReplyTo":"20060323204825.GE30176@spearce.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-03-23T21:11:51Z","receivedAt":"2006-03-23T21:11:51Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Thu, Mar 23, 2006 at 03:48:25PM -0500, Shawn Pearce wrote:\n> \n> But your definately right; once the blame/annotate war settles out\n> GIT will have pretty much everything one might need - except a good\n> distributed bug/issue tracking type system. :-)\n\nJunio, where do we stand on this?\n\nI've been a bit busy to finish the bug fixing I need to do on\nannotate[1], and frankly, I have no strong feelings either way.\n\nI must admit, I find annotate easier to read, but I wrote it, so I'm a\nbit biased. Maybe it is just that in C you sometimes get lost in the\ndetails.\n\n1 - The only bug I'm aware of, at the moment, is the fact that merges\nsometimes get assigned poorly, which I have a plan to fix, I just\nhaven't had the time to sort it out yet.\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"17826","messageId":"20060323.133120.69312511.davem@davemloft.net","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603231134160.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"David S. Miller","fromEmail":"davem@davemloft.net","sentAt":"2006-03-23T21:31:20Z","receivedAt":"2006-03-23T21:31:20Z","isPatch":false,"sender":{"key":"davem@davemloft.net","avatar":null},"body":"From: Linus Torvalds \nDate: Thu, 23 Mar 2006 12:38:33 -0800 (PST)\n\n> Yeah, I'm not counting things like Eclipse etc. I'm talking about \"plain \n> SCM\" environments, ie just basic SVN or CVS. What are we missing in that \n> department? (The only thing I can think of is a diff colorizer, which some \n> prople seem to really want).\n\ngitk does color the diffs already, or are we talking about some\n\"side-by-side\" multiple window thing showing \"before\" on the\nleft and \"after\" on the right?\n\nGiven that the gitk author has also written diff colorizers in the\npast, I don't see providing this as being much of a problem :)\n"},{"id":"17827","messageId":"Pine.LNX.4.64.0603231319120.26286@g5.osdl.org","threadId":"3698","inReplyTo":"20060323210215.GH26071@mythryan2.michonline.com","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-23T21:39:32Z","receivedAt":"2006-03-23T21:39:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Mar 2006, Ryan Anderson wrote:\n> \n> Scott Collins (QT evangelist, incredibly smart guy) commented to me\n> sometime over the summer, that every new SCM was born out of someone's\n> desire to implement a new merge algorithm. While I think that's too\n> simple, I think there have been an awful lot of academic SCMs out there.\n\nThe exact details are lost in antiquity, but I'm sure one of the defining \nmoments in time for CVS was Dick Grune saying \"Merges? We don't need no \nsteenking merges! We'll just make branching difficult! Yeah, that's it! \nMwhahahhahhaaaa!\".\n\nThe rest is history.\n\n[ Really, the sad part is that you're probably right even when it comes to \n CVS. The #1 feature of CVS as defined by Brian Berliner in his CVS II \n paper was 'Concurrent access and conflict-resolution algorithms to \n guarantee that source changes are not \"lost\"'. ]\n\n\t\t\tLinus\n"},{"id":"17829","messageId":"Pine.LNX.4.64.0603231347440.26286@g5.osdl.org","threadId":"3698","inReplyTo":"20060323.133120.69312511.davem@davemloft.net","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-23T21:48:42Z","receivedAt":"2006-03-23T21:48:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Mar 2006, David S. Miller wrote:\n> \n> > Yeah, I'm not counting things like Eclipse etc. I'm talking about \"plain \n> > SCM\" environments, ie just basic SVN or CVS. What are we missing in that \n> > department? (The only thing I can think of is a diff colorizer, which some \n> > prople seem to really want).\n> \n> gitk does color the diffs already, or are we talking about some\n> \"side-by-side\" multiple window thing showing \"before\" on the\n> left and \"after\" on the right?\n\nI think we're just talking about \n\n\tgit diff | git colorize\n\nlike this (and then integrating it a bit better).\n\n\t\tLinus\n\n--- colorize.c ---\n#include \"cache.h\"\n\n#define BUFSIZE 128\n\n#define NORMAL\t\"\"\n#define BOLD\t\"\\033[1m\"\n#define UL\t\"\\033[4m\"\n\n#define GRAYBG\t\"\\033[47m\"\n\n#define BLACK\t\"\\033[30m\"\n#define RED\t\"\\033[31m\"\n#define GREEN\t\"\\033[32m\"\n#define YELLOW\t\"\\033[33m\"\n#define BLUE\t\"\\033[34m\"\n#define MAGENTA\t\"\\033[35m\"\n#define CYAN\t\"\\033[36m\"\n#define WHITE\t\"\\033[37m\"\n#define RESET\t\"\\033[m\"\n\nenum linetype {\n\tUNKNOWN,\n\tHEAD,\n\tFRAGHEAD,\n\tADD,\n\tREMOVE,\n\tUNCHANGED,\n};\n\nstatic const char *tput[][2] = {\n\t[UNKNOWN] =\t{ NORMAL, NORMAL \"\\n\" },\n\t[HEAD] =\t{ BOLD, RESET \"\\n\" },\n\t[FRAGHEAD] =\t{ GRAYBG, RESET \"\\n\" },\n\t[ADD] =\t\t{ GREEN, RESET \"\\n\" },\n\t[REMOVE] =\t{ RED, RESET \"\\n\" },\n\t[UNCHANGED] =\t{ NORMAL, NORMAL \"\\n\" },\n};\n\nstatic void colorize(FILE *in, FILE *out)\n{\n\tchar buffer[BUFSIZE];\n\tconst char *end = NULL;\n\tint in_fragment = 0;\n\n\twhile (fgets(buffer, BUFSIZE, in)) {\n\t\tint type = UNKNOWN;\n\t\tint eoln, len = strlen(buffer);\n\t\tconst char *begin;\n\n\t\tif (!len)\n\t\t\tbreak;\n\t\teoln = buffer[len-1] == '\\n';\n\t\tif (eoln)\n\t\t\tbuffer[--len] = 0;\n\n\t\t/* Did we have a partial line from before? */\n\t\tif (end) {\n\t\t\tfputs(buffer, out);\n\t\t\tif (!eoln)\n\t\t\t\tcontinue;\n\t\t\tfputs(end, out);\n\t\t\tend = NULL;\n\t\t\tcontinue;\n\t\t}\n\n\t\tif (in_fragment) {\n\t\t\tin_fragment--;\n\t\t\tswitch (buffer[0]) {\n\t\t\tcase '+':\n\t\t\t\ttype = ADD;\n\t\t\t\tbreak;\n\t\t\tcase '-':\n\t\t\t\ttype = REMOVE;\n\t\t\t\tbreak;\n\t\t\tcase ' ':\n\t\t\t\ttype = UNCHANGED;\n\t\t\t\tbreak;\n\t\t\tcase '\\\\':\n\t\t\t\ttype = UNCHANGED;\n\t\t\t\tbreak;\n\t\t\tdefault:\n\t\t\t\tin_fragment = 0;\n\t\t\t}\n\t\t}\n\t\tif (type == UNKNOWN) {\n\t\t\tif (!strncmp(buffer, \"@@ \", 3)) {\n\t\t\t\ttype = FRAGHEAD;\n\t\t\t\t/* We should parse the line numbers */\n\t\t\t\tin_fragment = INT_MAX;\n\t\t\t}\n\t\t\tif (!strncmp(buffer, \"+++ \", 4) ||\n\t\t\t !strncmp(buffer, \"--- \", 4) ||\n\t\t\t !strncmp(buffer, \"diff \", 5))\n\t\t\t\ttype = HEAD;\n\t\t}\n\n\t\tbegin = tput[type][0];\n\t\tend = tput[type][1];\n\t\tfputs(begin, out);\n\t\tfputs(buffer, out);\n\t\tif (!eoln)\n\t\t\tcontinue;\n\t\tfputs(end, out);\n\t\tend = NULL;\n\t}\n\tif (end)\n\t\tfputs(end, out);\n}\n\nint main(int argc, char **argv)\n{\n\tcolorize(stdin, stdout);\n\treturn 0;\n}\n"},{"id":"17831","messageId":"BAYC1-PASMTP029991B795201E8474F772AEDE0@CEZ.ICE","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603231134160.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-03-23T22:05:15Z","receivedAt":"2006-03-23T22:05:15Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 23 Mar 2006 12:38:33 -0800 (PST)\nLinus Torvalds wrote:\n\n> Actually, as far as I can tell, git already has a hell of a lot more \n> porcelain than pretty much any non-IDE type traditional SCM. Certainly \n> more than CVS.\n> \n> Yeah, I'm not counting things like Eclipse etc. I'm talking about \"plain \n> SCM\" environments, ie just basic SVN or CVS. What are we missing in that \n> department? (The only thing I can think of is a diff colorizer, which some \n> prople seem to really want).\n\nYeah, i was thinking more along the lines of the way cogito handles\ncommit message editing for example, where you can change which files\nare committed by editing the file list in place. Maybe the colorized\ngit log viewer would be worth pulling into core as well, etc.\n\nIt's been a long time since i've looked at cogito but perhaps there\nare other things in it that have proven useful and deserve to \nbe pushed into core.\n\nI guess my original comment was made because I always cringe when\ni see git described as \"plumbing\" and only having porcelain-\"ish\"\ncommands included.\n\nSean\n"},{"id":"17832","messageId":"20060324003653.b1cd7624.tihirvon@gmail.com","threadId":"3698","inReplyTo":"20060323.133120.69312511.davem@davemloft.net","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-03-23T22:36:53Z","receivedAt":"2006-03-23T22:36:53Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"On Thu, 23 Mar 2006 13:31:20 -0800 (PST)\n\"David S. Miller\" wrote:\n\n> From: Linus Torvalds \n> Date: Thu, 23 Mar 2006 12:38:33 -0800 (PST)\n> \n> > Yeah, I'm not counting things like Eclipse etc. I'm talking about \"plain \n> > SCM\" environments, ie just basic SVN or CVS. What are we missing in that \n> > department? (The only thing I can think of is a diff colorizer, which some \n> > prople seem to really want).\n> \n> gitk does color the diffs already, or are we talking about some\n> \"side-by-side\" multiple window thing showing \"before\" on the\n> left and \"after\" on the right?\n\nColorized \"git diff\", like cg-diff. Vim users can use vimpager instead\nof less.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"17836","messageId":"7vslp84u43.fsf@assigned-by-dhcp.cox.net","threadId":"3698","inReplyTo":"20060323204825.GE30176@spearce.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-23T23:30:20Z","receivedAt":"2006-03-23T23:30:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> I'm not trying to bash Windows users. I'm just saying that there's\n> definately a large user base for SCMs such as CVS who just want\n> to check in the latest version of a file they have to maintain.\n> Many of these people are afraid of a command prompt. Asking them\n> to install Cygwin just to check in a file is a difficult challenge.\n\nExport your git repository via git-cvsserver and have them use\nTortoiseCVS. Such \"maintain the tip and that is the only thing\nwhat interest me\" people do not even need to know the backend is\ngit.\n"},{"id":"17839","messageId":"7vacbg4t48.fsf@assigned-by-dhcp.cox.net","threadId":"3698","inReplyTo":"20060323210215.GH26071@mythryan2.michonline.com","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-23T23:51:51Z","receivedAt":"2006-03-23T23:51:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson writes:\n\n> Git has taken a very pragmatic approach, in that the goal has been \"What\n> is the smallest number of concepts we can create that let us solve the\n> problem, even if we occassionally have to make some tradeoffs?\"\n> (Thinking of rename detection there, mostly.)\n\nI do not see it as a tradeoff not to record renames. It _is_ a\nfeature.\n\nOn the other hand, rename detection is an eye candy, which is\nsometimes useful but only sometimes. If you look at the history\nof a real project, content movement across multiple files is a\nnorm, and content movement between two files, one of which\ndisappears and the other appears, is a rather narrow special\ncase. If you think in terms of \"renames\", you can only talk\nabout that special case, and rename detection also can only deal\nwith that special case.\n\nTwo good examples were discussed some time ago on the list. One\nwas about \"where did {powerpc,pcc64}/Makefile come from?\" and\nthe answer was \"content migrated over time across multiple\ncommits, and you cannot really say this Makefile is renamed from\nsomewhere\". The other was the comment by Linus on how\nrevision.c evolved in our project.\n\nI am reasonably happy with how our rename detection turned out\nto be, but we should keep in mind that detecting file renames is\nscratching only a narrowly defined subset of the problem space.\n\nPickaxe was an attempt to help tracking other forms of content\nmovement, and it is minimally useful as a building block, but if\nwe really want to track content movement across file boundaries,\nlike Linus originally envisioned in \n\n\thttp://article.gmane.org/gmane.comp.version-control.git/217\n\nwe need to have a bit more Porcelain around it.\n"},{"id":"17840","messageId":"20060324000640.GK26071@mythryan2.michonline.com","threadId":"3698","inReplyTo":"7vacbg4t48.fsf@assigned-by-dhcp.cox.net","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-03-24T00:06:40Z","receivedAt":"2006-03-24T00:06:40Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Thu, Mar 23, 2006 at 03:51:51PM -0800, Junio C Hamano wrote:\n> Ryan Anderson writes:\n> \n> > Git has taken a very pragmatic approach, in that the goal has been \"What\n> > is the smallest number of concepts we can create that let us solve the\n> > problem, even if we occassionally have to make some tradeoffs?\"\n> > (Thinking of rename detection there, mostly.)\n> \n> I do not see it as a tradeoff not to record renames. It _is_ a\n> feature.\n\nOh, I don't disagree.\n\nWhat I was getting at was that not recording renames means we've traded\noff a little bit of speed and maybe accuracy, when we care about\nrenames, for a simpler, better implementation.\n\nIt's a tradeoff, but one that was very much the right decision, IMO.\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"17841","messageId":"7vveu43dh5.fsf@assigned-by-dhcp.cox.net","threadId":"3698","inReplyTo":"20060323211151.GI26071@mythryan2.michonline.com","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-24T00:15:02Z","receivedAt":"2006-03-24T00:15:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson writes:\n\n> On Thu, Mar 23, 2006 at 03:48:25PM -0500, Shawn Pearce wrote:\n>> \n>> But your definately right; once the blame/annotate war settles out\n>> GIT will have pretty much everything one might need - except a good\n>> distributed bug/issue tracking type system. :-)\n>\n> Junio, where do we stand on this?\n\nAs far as I am concerned, you two are still on the starting\nline. Admittably, Fredrik took a bit more time to come to there\nwhile you were still waiting there. But since then I do not\nthink either of you moved much.\n\nI have not seen anybody to come up with a test history, compare\nwhat the two algorithms do on that test history, and argue why\none is more correct than the other. I've been too busy to start\nthat myself, and honestly speaking I am not that interested in\nthe details myself in that area.\n\nTo me, the only reason annotate/blame exist in git is to support\nthe cvs server emulation, so obviously I want at least _one_ of\nthem working correctly to be usable by git-cvsserver, but beyond\nthat, which one to pick is not really what I am interested in.\nWhen I am working in a git repository, I'd rather use\ncombination of whatchanged and pickaxe not annotate/blame myself\nanyway.\n\nI suspect there are people a lot more interested in having a\nbetter annotate/blame, and I've been sort-of hoping somebody\nwould really start that blame/annotate war.\n"},{"id":"17842","messageId":"7vpskc3clj.fsf@assigned-by-dhcp.cox.net","threadId":"3698","inReplyTo":"20060324000640.GK26071@mythryan2.michonline.com","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-24T00:34:00Z","receivedAt":"2006-03-24T00:34:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson writes:\n\n> What I was getting at was that not recording renames means we've traded\n> off a little bit of speed and maybe accuracy, when we care about\n> renames, for a simpler, better implementation.\n>\n> It's a tradeoff, but one that was very much the right decision, IMO.\n\nWell, that is like arguing that we do not autocommit every time\nthe user makes any change in the working tree -- which means git\ncannot be used to go back to _any_ time in history -- but we are\nmaking that tradeoff and instead letting the user to decide\nexplicitly when to make commits.\n\nRecording every keystrokes _is_ a wrong feature and not\nsupporting a wrong feature _is_ a feature. It is not a\ntradeoff.\n\nWhen I said \"not recording renames _is_ a feature\", I really\nmeant it that way.\n"},{"id":"17843","messageId":"20060324003944.GA28652@pe.Belkin","threadId":"3698","inReplyTo":"20060323200306.GG31387@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2006-03-24T00:39:44Z","receivedAt":"2006-03-24T00:39:44Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:\n> On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds wrote:\n> > On Wed, 22 Mar 2006, Linus Torvalds wrote:\n> > > This one-liner to cvsps.c seems to make sure we have an ancestor branch \n> > > for that \"gdb-4.18-branch\" branch, at least according to the cvsps output. \n> > \n> > The \"git cvsimport\" is still running, but at least it seems to be happily \n> > running further past the point it broke earlier.\n> \n> I've started it once again, too, with the one-liner added to Debian\n> unstable's version of cvsps:\n> \n> It seems there's a patch like\n> http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?\n> ...or we need a better cvsps. Shall I add it and try again / try to\n> continue, or give up on it for now? Though it would be nice to have\n> these two large and important source trees under GIT control :-)\n\nYou make want to try the cvsps patch I attached to the email here:\n\nhttp://www.gelato.unsw.edu.au/archives/git/0511/11812.html\n\nGood luck!\n\n-chris\n"},{"id":"17851","messageId":"1143180778.6850.55.camel@neko.keithp.com","threadId":"3698","inReplyTo":"20060324003944.GA28652@pe.Belkin","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-03-24T06:12:58Z","receivedAt":"2006-03-24T06:12:58Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Thu, 2006-03-23 at 19:39 -0500, Chris Shoemaker wrote:\n> On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:\n> > On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds wrote:\n> > > On Wed, 22 Mar 2006, Linus Torvalds wrote:\n> > > > This one-liner to cvsps.c seems to make sure we have an ancestor branch \n> > > > for that \"gdb-4.18-branch\" branch, at least according to the cvsps output. \n> > > \n> > > The \"git cvsimport\" is still running, but at least it seems to be happily \n> > > running further past the point it broke earlier.\n> > \n> > I've started it once again, too, with the one-liner added to Debian\n> > unstable's version of cvsps:\n> > \n> > It seems there's a patch like\n> > http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?\n> > ...or we need a better cvsps. Shall I add it and try again / try to\n> > continue, or give up on it for now? Though it would be nice to have\n> > these two large and important source trees under GIT control :-)\n\nI'm busy writing a new import tool to get X into git; I've got it\ngenerating complete revision trees in memory, and dumping them in\ngraphviz form. I'd sure be interested to see how well this works with\nother ancient and broken CVS trees. Once I've got it dealing with\ncurrent X.org CVS correctly (or, at least, reasonably), I'll finish it\nup and get it to actually generate the repository.\n\ngit://git.freedesktop.org/~keithp/parsecvs\n\nUsage is completely lame at present -- a list of ,v file names either on\nthe command line or via stdin (one name per line). The .dot file is\noutput on stdout, with some diagnostics on stderr.\n\nPipe this through 'dot -Tsvg' and you'll get a .svg file which can be\nviewed with inkscape. They're generally immense...\n\n-- \nkeith.packard@intel.com\n"},{"id":"17854","messageId":"20060324075229.GH31387@lug-owl.de","threadId":"3698","inReplyTo":"20060324003944.GA28652@pe.Belkin","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-03-24T07:52:29Z","receivedAt":"2006-03-24T07:52:29Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Thu, 2006-03-23 19:39:44 -0500, Chris Shoemaker wrote:\n> On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:\n> > On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds wrote:\n> > It seems there's a patch like\n> > http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?\n> > ...or we need a better cvsps. Shall I add it and try again / try to\n> > continue, or give up on it for now? Though it would be nice to have\n> > these two large and important source trees under GIT control :-)\n> \n> You make want to try the cvsps patch I attached to the email here:\n> \n> http://www.gelato.unsw.edu.au/archives/git/0511/11812.html\n\n[...]\ncvs rlog: Logging src/winsup/w32api/include/ddk\ncvs rlog: Logging src/winsup/w32api/include/directx\ncvs rlog: Logging src/winsup/w32api/lib\ncvs rlog: Logging src/winsup/w32api/lib/ddk\ncvs rlog: Logging src/winsup/w32api/lib/directx\ninvalid initial_branch for file bfd/po/BLD-POTFILES.in, probably from old cache, run with -x.\nDONE; creating master branch\nfatal: refs/heads/origin: not a valid SHA1\nfatal: master: not a valid SHA1\nfatal: 'HEAD': No such file or directory\nusage: git-read-tree ( | -m [--aggressive] [-u | -i] [ []])\ncheckout failed: 256\n\n\nSo it fails pretty early this time :)\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"17863","messageId":"slrne27kv8.cp6.mdw@metalzone.distorted.org.uk","threadId":"3698","inReplyTo":"20060323204825.GE30176@spearce.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-03-24T11:11:36Z","receivedAt":"2006-03-24T11:11:36Z","isPatch":false,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Shawn Pearce wrote:\n\n> But your definately right; once the blame/annotate war settles out\n> GIT will have pretty much everything one might need - except a good\n> distributed bug/issue tracking type system. :-)\n\nThere ought to be such a thing. And I hope it gets called `bugger'.\n\n-- [mdw]\n"},{"id":"17865","messageId":"4423D808.7070800@op5.se","threadId":"3698","inReplyTo":"slrne27kv8.cp6.mdw@metalzone.distorted.org.uk","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-24T11:29:12Z","receivedAt":"2006-03-24T11:29:12Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Mark Wooding wrote:\n> Shawn Pearce wrote:\n> \n> \n>>But your definately right; once the blame/annotate war settles out\n>>GIT will have pretty much everything one might need - except a good\n>>distributed bug/issue tracking type system. :-)\n> \n> \n> There ought to be such a thing. And I hope it gets called `bugger'.\n> \n\nI'm working (slowly) on integrating it with Mantis (www.mantisbt.org), \nwhich we use at work. It shouldn't be difficult to reuse that code with \nBugzilla and other similar trackers.\n\nThe recognition thing is done in the update-script, looking for a hash \nfollowed by a number (the bug-id) and then sending that commit to \nanother program, so it's simply a matter of including the bug-id, \nprefixed with a hash, and the bug-topic somewhere in the commit message, \nwhich is a fairly good practice anyways.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"17867","messageId":"20060324123238.GA3070@linux-mips.org","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603231134160.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Ralf Baechle","fromEmail":"ralf@linux-mips.org","sentAt":"2006-03-24T12:32:38Z","receivedAt":"2006-03-24T12:32:38Z","isPatch":false,"sender":{"key":"ralf@linux-mips.org","avatar":null},"body":"On Thu, Mar 23, 2006 at 12:38:33PM -0800, Linus Torvalds wrote:\n\n> > lol, that sounds like a really good plan. Perhaps as a two pronged effort\n> > its worth changing the notion that git is primarily \"plumbing\". Adding\n> > some of the nice features of cogito and other \"porcelains\" into the core\n> > git might go a ways toward converting the few naysayers we don't kill.\n> \n> Actually, as far as I can tell, git already has a hell of a lot more \n> porcelain than pretty much any non-IDE type traditional SCM. Certainly \n> more than CVS.\n> \n> Yeah, I'm not counting things like Eclipse etc. I'm talking about \"plain \n> SCM\" environments, ie just basic SVN or CVS. What are we missing in that \n> department? (The only thing I can think of is a diff colorizer, which some \n> prople seem to really want).\n\nI'd like sunglasses with that diff colouriser, please ;-)\n\nFor my various hacking projects and archiving needs git has done me alot\nof good and it's pretty close to the answer to the question for life,\nuniverse and everything. But a few rough areas (I'm currently using git\n1.2.4 btw.) remain:\n\n o During the debugging phase before a new kernel release I put anything\n that isn't appropriate for the master branch on a queue branch which\n I am rebasing frequently to ensure things will work right in the\n \"patch bombing\" phase before the next -rc1 when I'm sending everything\n on the queue branch upstream.\n The problem: users pull such a branch, create their own branch starting\n somewhere on my queue branch. So eventually when they pull again\n after I rebased the branch things blow up spectactularly. This needs a\n simple solution.\n o git rebase had no reasonable handling of conflicts last I ran into a\n rebase conflict.\n o If a file is modified in a user's tree and a non-conflicting patch is\n being pull users seem to expect the old CVS behaviour which is trying\n to merge into the checked out tree, worst case adding conflict markers.\n Git just refuses the operation.\n o I had people piling up over 2GB in their $GIT_DIR/objects/pack/\n directory because they were using the rsync method for updating.\n o Git is a dramatically more powerful and for most operations better\n performing SCM than CVS - but CVS is what people know, it's easy to\n learn and handling special cases like conflicts is sort of obvious\n because CVS expects the user to cleanup the mess and does not try to\n compete with the users in that.\n o A Git for Dummies book would be helpful.\n o When users have problems with git I found it useful to explain them\n how git internally works so they get a better understanding of what\n actually is going on. Dominic Sweetman which is an excellent\n technical writer has made a similar experience and started writing\n a bit about git in the wiki at http://www.linux-mips.org/wiki/WhatIsGit\n May somebody wants to extend this?\n (Dominic unfortunately is currently deeply burried in writing the\n 2nd issue of See MIPS Run, so can't really contribute ...)\n\n Ralf\n"},{"id":"17868","messageId":"20060324124410.GB3070@linux-mips.org","threadId":"3698","inReplyTo":"Pine.LNX.4.64.0603221517210.26286@g5.osdl.org","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Ralf Baechle","fromEmail":"ralf@linux-mips.org","sentAt":"2006-03-24T12:44:10Z","receivedAt":"2006-03-24T12:44:10Z","isPatch":false,"sender":{"key":"ralf@linux-mips.org","avatar":null},"body":"On Wed, Mar 22, 2006 at 03:39:00PM -0800, Linus Torvalds wrote:\n\n> it's \"PatchSet 104\" (well, for me it is, I have a hacked cvsps, so it \n> might not be that for you), which creates the \"gdb-4_18-branch\", but it \n> appears that cvsps hasn't actually figured out any \"Ancestor branch\" for \n> that commit.\n> \n> What a crock.\n> \n> Anyway, it's clearly a cvsps bug (mentioning a new branch without the \n> _source_ of that branch). Equally clearly, \"git cvsimport\" is being an ass \n> about then failing so totally on it.\n> \n> I'll try to take a look at why cvsps does that.\n\nLast I converted CVS trees to git found that about half of the branches\nwere branching off from the wrong commit of the parent branch. At that\ntime I decieded to just move the branch using a quick script instead of\ndiving into cvsps.\n\n Ralf\n"},{"id":"17869","messageId":"4423ED16.9080504@op5.se","threadId":"3698","inReplyTo":"20060324123238.GA3070@linux-mips.org","subject":"Re: missing git features (was: Re: Errors GITtifying GCC and Binutils)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-24T12:59:02Z","receivedAt":"2006-03-24T12:59:02Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ralf Baechle wrote:\n> \n> For my various hacking projects and archiving needs git has done me alot\n> of good and it's pretty close to the answer to the question for life,\n> universe and everything. But a few rough areas (I'm currently using git\n> 1.2.4 btw.) remain:\n> \n> o During the debugging phase before a new kernel release I put anything\n> that isn't appropriate for the master branch on a queue branch which\n> I am rebasing frequently to ensure things will work right in the\n> \"patch bombing\" phase before the next -rc1 when I'm sending everything\n> on the queue branch upstream.\n> The problem: users pull such a branch, create their own branch starting\n> somewhere on my queue branch. So eventually when they pull again\n> after I rebased the branch things blow up spectactularly. This needs a\n> simple solution.\n\nSee how Junio does with next and pu and recommend your users to do the \nsame. There's no way of pulling a rebased branch, because the rebasing \ndestroys ancestry information, meaning the original commits other people \nhave cease to exist in your repository.\n\n> o git rebase had no reasonable handling of conflicts last I ran into a\n> rebase conflict.\n\n\"git rerere\" might be of service here. Other than that, it's merging \nthat goes, unless we come up with a way of patching the delta on the fly \nwhen such things are encountered. Unfortunately that is beyond me, but \nperhaps there are other takers on the list. It would indeed be very nice \nto have.\n\n> o If a file is modified in a user's tree and a non-conflicting patch is\n> being pull users seem to expect the old CVS behaviour which is trying\n> to merge into the checked out tree, worst case adding conflict markers.\n> Git just refuses the operation.\n\nA pull (fetch + merge) requires a pristine index. If the user has done \n\"git update-index\" on the files, but not committed the merge *should* \nfail every time. If they have changes in the working tree but not in the \nindex, the fetch should work, but the final phase (checking out the \nupdated head) should fail, since the working tree has un-committed changes.\n\n\n> o I had people piling up over 2GB in their $GIT_DIR/objects/pack/\n> directory because they were using the rsync method for updating.\n\nThis most likely happens because you're doing too large packs. You can \ndo incremental packing, or ask users to switch to using the git:// \nprotocol, which is much faster for incremental updates.\n\n> o Git is a dramatically more powerful and for most operations better\n> performing SCM than CVS - but CVS is what people know, it's easy to\n> learn and handling special cases like conflicts is sort of obvious\n> because CVS expects the user to cleanup the mess and does not try to\n> compete with the users in that.\n\n\ngit doesn't compete with the user either, but it doesn't touch the \nworking tree unless the merge succeeds, which is sane imo but surprising \nfor CVS users where the action is done in the working tree and the \nresult is put under rcs control.\n\n\n> o A Git for Dummies book would be helpful.\n\nThe tutorial is fairly complete.\n\nhttp://www.kernel.org/pub/software/scm/git/docs/tutorial.html\n\n> o When users have problems with git I found it useful to explain them\n> how git internally works so they get a better understanding of what\n> actually is going on. Dominic Sweetman which is an excellent\n> technical writer has made a similar experience and started writing\n> a bit about git in the wiki at http://www.linux-mips.org/wiki/WhatIsGit\n> May somebody wants to extend this?\n> (Dominic unfortunately is currently deeply burried in writing the\n> 2nd issue of See MIPS Run, so can't really contribute ...)\n> \n\nGood to know. Unfortunately I don't know git internals half as well as I \nwould like. I can sometimes answer questions, but starting from scratch \nand explain it is beyond me.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"17874","messageId":"Pine.LNX.4.63.0603241609510.6002@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3698","inReplyTo":"7vslp84u43.fsf@assigned-by-dhcp.cox.net","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-24T15:12:57Z","receivedAt":"2006-03-24T15:12:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 23 Mar 2006, Junio C Hamano wrote:\n\n> Shawn Pearce writes:\n> \n> > I'm not trying to bash Windows users. I'm just saying that there's\n> > definately a large user base for SCMs such as CVS who just want\n> > to check in the latest version of a file they have to maintain.\n> > Many of these people are afraid of a command prompt. Asking them\n> > to install Cygwin just to check in a file is a difficult challenge.\n> \n> Export your git repository via git-cvsserver and have them use\n> TortoiseCVS. Such \"maintain the tip and that is the only thing\n> what interest me\" people do not even need to know the backend is\n> git.\n\nNow if I could only find a way to tell TortoiseCVS which CVS_SERVER to \nuse...\n\nCiao,\nDscho\n"},{"id":"17879","messageId":"871wwrztaz.wl%cworth@cworth.org","threadId":"3698","inReplyTo":"4423ED16.9080504@op5.se","subject":"Re: missing git features (was: Re: Errors GITtifying GCC and Binutils)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-03-24T16:44:20Z","receivedAt":"2006-03-24T16:44:20Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 24 Mar 2006 13:59:02 +0100, Andreas Ericsson wrote:\n> See how Junio does with next and pu and recommend your users to do the \n> same. There's no way of pulling a rebased branch, because the rebasing \n> destroys ancestry information, meaning the original commits other people \n> have cease to exist in your repository.\n\nBut the \"other people\" still have those commits, so it should be\nrather straightforward for a tool to also perform a rebase for them\nwhen doing this kind of \"rebased pull\". I think there's just a single\narc of data missing showing where a rebased commit object came from.\n\nSo this sounds solvable, and it is something I would very much enjoy\nhaving, (call me funny, but I prefer to rebase and avoid a merge\ncommit when looking at independent lines of development for which\nlogically there shouldn't be any \"merge\" required).\n\n-Carl\n"},{"id":"17885","messageId":"20060324182504.GI31387@lug-owl.de","threadId":"3698","inReplyTo":"20060322133337.GU20746@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-03-24T18:25:04Z","receivedAt":"2006-03-24T18:25:04Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw wrote:\n\nSince it seems nobody looked at the GCC import run (which means to use\nthe svnimport), I ran it again, under strace control:\n\n> GCC\n> ~~~\n> $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc\n\n> Committed change 3936:/ 1993-03-31 05:44:03)\n> Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e\n> Writing to refs/heads/origin\n> DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e\n> ... 3937 trunk/gcc/final.c ...\n> Can't fork at /home/jbglaw/bin/git-svnimport line 379.\n\n... 4279 trunk/gcc/config/i386/xm-sco.h ...\n\nThis time it broke at a different revision, so I guess it's not a SVN\nor git / git-svnimport problem, but rather a problem of my Perl\ninstallation or the kernel itself?\n\nTree ID 5b04fbc98f8dc9d50506b6dbc8f31567eea2e225\nCommitted change 4279:/ 1993-04-29 21:13:46)\nMerge parent branch: eeb742d8ffd78d58f05d0b9c80bb55e1dc25ad13\nCommit ID e85129f5e8af0b93a41d5bf294f17a9c9bf9fa21\nWriting to refs/heads/origin\nDONE: 4279 origin e85129f5e8af0b93a41d5bf294f17a9c9bf9fa21\n... 4280 trunk/gcc/config/mips/mips.h ...\nTree ID 3feb45ec3ee93e8a6d75b8ce552281e0ed2d7215\nCommitted change 4280:/ 1993-04-30 00:53:35)\nMerge parent branch: e85129f5e8af0b93a41d5bf294f17a9c9bf9fa21\nCommit ID 34b473ffc0e05419c50be848d5349592b7c48ee3\nWriting to refs/heads/origin\nDONE: 4280 origin 34b473ffc0e05419c50be848d5349592b7c48ee3\nreadline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.\n4281: cannot find commit 'origin'!\nreadline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.\n4282: cannot find commit 'origin'!\nreadline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.\n4283: cannot find commit 'origin'!\nreadline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.\n4284: cannot find commit 'origin'!\nreadline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.\n4285: cannot find commit 'origin'!\n... 4286 trunk/gcc/fixincludes ...\nCan't fork at /home/jbglaw/bin/git-svnimport line 379.\n\n\nstrace of this:\n\nread(3, \"rintf decl\"..., 4096) = 2896\nwrite(6, \"superfluou\"..., 4096) = 4096\nread(3, \"$file ${LI\"..., 4096) = 1448\nread(3, \"m -f ${LIB\"..., 4096) = 1448\nread(3, \"LIB}/machi\"..., 4096) = 1448\nwrite(6, \" 2>/dev/nu\"..., 4096) = 4096\nread(3, \"memory\\\\.h\"..., 4096) = 2896\nread(3, \"h>\\\") > ${\"..., 4096) = 1448\nwrite(6, \"&& [ ! -r \"..., 4096) = 4096\nread(3, \" char *__n\"..., 4096) = 3438\nwrite(6, \"claim to h\"..., 4096) = 4096\nwrite(6, \"ymbolic no\"..., 446) = 446\nclose(6) = 0\npipe([6, 7]) = 0\nclone(child_stack=0,\nflags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,\nchild_tidptr=0xb7ddf708) = -1 ENOMEM (Cannot allocate memory)\nclose(6) = 0\nclose(7) = 0\nwrite(2, \"Can\\'t for\"..., 55) = 55\nclose(4) = 0\nclose(3) = 0\n\nWhat are possible reasons for clone() to fail with -ENOMEN? I have to\nadmit that the box _is_ loaded a bit all the time:\n\njbglaw@bixie:~/vax/git-conversion$ uptime\n 19:23:58 up 136 days, 7:46, 20 users, load average: 4.45, 4.25, 3.05\njbglaw@bixie:~/vax/git-conversion$ free\n total used free shared buffers cached\nMem: 507308 501760 5548 0 2184 16900\n-/+ buffers/cache: 482676 24632\nSwap: 2441872 1295512 1146360\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"17888","messageId":"4424409A.80503@op5.se","threadId":"3698","inReplyTo":"871wwrztaz.wl%cworth@cworth.org","subject":"Re: missing git features","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-24T18:55:22Z","receivedAt":"2006-03-24T18:55:22Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Carl Worth wrote:\n> On Fri, 24 Mar 2006 13:59:02 +0100, Andreas Ericsson wrote:\n> \n>>See how Junio does with next and pu and recommend your users to do the \n>>same. There's no way of pulling a rebased branch, because the rebasing \n>>destroys ancestry information, meaning the original commits other people \n>>have cease to exist in your repository.\n> \n> \n> But the \"other people\" still have those commits, so it should be\n> rather straightforward for a tool to also perform a rebase for them\n> when doing this kind of \"rebased pull\".\n\n\nYes they do, but you don't, so their tip won't match yours, meaning \ntheir git will try a merge, which will fail since lots of commits are \nalready applied. Perhaps it would be possible to try the blobs against \neach other, if anyone's interested.\n\n\n> I think there's just a single\n> arc of data missing showing where a rebased commit object came from.\n> \n> So this sounds solvable, and it is something I would very much enjoy\n> having, (call me funny, but I prefer to rebase and avoid a merge\n> commit when looking at independent lines of development for which\n> logically there shouldn't be any \"merge\" required).\n> \n\nFor the cases where no merge is required you could rebase several \nbranches on top of one and simply publish that one. If that's the case, \ngit would need the ability to know what branches are exported and which \narne't, which should be a lot simpler than implementing a rebased-merge \nstrategy.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"17890","messageId":"4424443F.5090209@op5.se","threadId":"3698","inReplyTo":"20060324182504.GI31387@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-24T19:10:55Z","receivedAt":"2006-03-24T19:10:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jan-Benedict Glaw wrote:\n> On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw wrote:\n> \n> Since it seems nobody looked at the GCC import run (which means to use\n> the svnimport), I ran it again, under strace control:\n> \n\nIf you send me a bzipped tar-ball of the repo you're trying to import, \npreferrably with all the patches to cvsps you've tried, I'll see what I \ncan do over the weekend.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"17891","messageId":"87fyl7k554.fsf@gmail.com","threadId":"3698","inReplyTo":"20060324182504.GI31387@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-03-24T19:35:19Z","receivedAt":"2006-03-24T19:35:19Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"Jan-Benedict Glaw writes:\n\n> On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw wrote:\n>\n> Since it seems nobody looked at the GCC import run (which means to use\n> the svnimport), I ran it again, under strace control:\n>\n>> GCC\n>> ~~~\n>> $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc\n>\n>> Committed change 3936:/ 1993-03-31 05:44:03)\n>> Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e\n>> Writing to refs/heads/origin\n>> DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e\n>> ... 3937 trunk/gcc/final.c ...\n>> Can't fork at /home/jbglaw/bin/git-svnimport line 379.\n>\n\nI have the same (?) problem with one of my svn repository. It worked\nbefore (I've redone the import with the -r flag), so I bisected it.\nThe problematic commit seems to be:\n\ndiff-tree 4802426... (from 525c0d7...)\nAuthor: Karl Hasselström \nDate: Sun Feb 26 06:11:27 2006 +0100\n\n svnimport: Convert executable flag\n\n Convert the svn:executable property to file mode 755 when converting\n an SVN repository to GIT.\n\n Signed-off-by: Karl Hasselström \n Signed-off-by: Junio C Hamano \n\n:100755 100755 ee2940f... 6603b96... M git-svnimport.perl\n\nI think it has a memory leak, it used up to 140m of memory.\n\n$ git reset --hard 4802426^\n$ time ../git-svnimport.perl file:///path/\nUse of uninitialized value in string eq at ../git-svnimport.perl line 463.\nUse of uninitialized value in substitution (s///) at ../git-svnimport.perl line 466.\nreal 0m55.801s\nuser 0m30.578s\nsys 0m23.084s\n\n$ git reset --hard 4802426\n$ time ../git-svnimport.perl file:///path/\nUse of uninitialized value in string eq at ../git-svnimport.perl line 463.\nUse of uninitialized value in substitution (s///) at ../git-svnimport.perl line 466.\nCan't fork at /home/santi/usr/src/scm/git/git-svnimport.perl line 331.\nreal 6m2.163s\nuser 0m20.332s\nsys 0m50.180s\n\nand it didn't finished. Hope it helps.\n\nSanti\n"},{"id":"17896","messageId":"20060325003712.GA32320@pe.Belkin","threadId":"3698","inReplyTo":"20060324075229.GH31387@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2006-03-25T00:37:12Z","receivedAt":"2006-03-25T00:37:12Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Fri, Mar 24, 2006 at 08:52:29AM +0100, Jan-Benedict Glaw wrote:\n> On Thu, 2006-03-23 19:39:44 -0500, Chris Shoemaker wrote:\n> > On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:\n> > > On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds wrote:\n> > > It seems there's a patch like\n> > > http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?\n> > > ...or we need a better cvsps. Shall I add it and try again / try to\n> > > continue, or give up on it for now? Though it would be nice to have\n> > > these two large and important source trees under GIT control :-)\n> > \n> > You make want to try the cvsps patch I attached to the email here:\n> > \n> > http://www.gelato.unsw.edu.au/archives/git/0511/11812.html\n> \n> [...]\n\n> invalid initial_branch for file bfd/po/BLD-POTFILES.in, probably\n> from old cache, run with -x.\n\nI guess that error message wasn't quite as obvious as I intended.\n\nThat means you have old cvsps cache state hanging around. You can\neither run cvsps with -x or delete the cache file manually. Those are\nthe files in ~/.cvsps.\n\nIncidentally, I'd recommend doing this in two stages during\ntrouble-shooting. Run cvsps first and verify that you can produce a\nvalid ancestry tree. If it's not-quite-right you can even edit the\ncvsps output to reparent the incorrect branches. Then run\ngit-cvsimport after you're satisfied with the ancestry.\n\n-chris\n"},{"id":"17915","messageId":"20060325082521.GA17473@hand.yhbt.net","threadId":"3698","inReplyTo":"20060324182504.GI31387@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-03-25T08:25:21Z","receivedAt":"2006-03-25T08:25:21Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jan-Benedict Glaw wrote:\n> On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw wrote:\n> \n> Since it seems nobody looked at the GCC import run (which means to use\n> the svnimport), I ran it again, under strace control:\n\nIf you don't care for automated branch handling, how about trying git-svn?\nunder the contrib/ directory in git.git\n\n\tgit-svn init svn://gcc.gnu.org/svn/gcc\n\tgit-svn fetch\n\n> > GCC\n> > ~~~\n> > $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc\n> \n> > Committed change 3936:/ 1993-03-31 05:44:03)\n> > Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e\n> > Writing to refs/heads/origin\n> > DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e\n> > ... 3937 trunk/gcc/final.c ...\n> > Can't fork at /home/jbglaw/bin/git-svnimport line 379.\n> \n> ... 4279 trunk/gcc/config/i386/xm-sco.h ...\n> \n> This time it broke at a different revision, so I guess it's not a SVN\n> or git / git-svnimport problem, but rather a problem of my Perl\n> installation or the kernel itself?\n\nI've known of SVN library bindings leaking memory in the past, but I\nthought it's been solved. Afaik, any memory allocated by the Perl\ninterpreter is never released back to the kernel, either. (At least\nthat seems to be the case with my setup (Debian unstable, Perl 5.8.8,\n2.6 kernel, x86 machine).\n\n> What are possible reasons for clone() to fail with -ENOMEN? I have to\n> admit that the box _is_ loaded a bit all the time:\n> \n> jbglaw@bixie:~/vax/git-conversion$ uptime\n> 19:23:58 up 136 days, 7:46, 20 users, load average: 4.45, 4.25, 3.05\n> jbglaw@bixie:~/vax/git-conversion$ free\n> total used free shared buffers cached\n> Mem: 507308 501760 5548 0 2184 16900\n> -/+ buffers/cache: 482676 24632\n> Swap: 2441872 1295512 1146360\n\nSome importers (my own git-svn included) aren't amazingly efficient when\nhandling lots of history which gcc has. It looks like (from what I\nunderstand of the SVN api used in git-svnimport) is that the entire log\nfor the 100k+ revisions in the tree is slurped down into memory before\nany processing is done.\n\ngit-svn does this too, but by parsing the output of the svn binary\ninstead of using the library, so at least it won't have issues with the\nsvn bindings and libraries to worry about.\n\nMy git-svn process running on the SVN tree just finished parsing the svn\nlog output, and it's maxed out at 74M RSS (on a 32-bit x86). It'll\nprobably take a while to import it all (which I won't do), but I could\nhave just as easily done the following to reduce memory usage by ~half:\n\n\tgit-svn fetch -r0:50000\t\t# import the first 50000k\n\tgit-svn fetch\t\t\t# now import the remaining\n\nAfaik, there's no way to do something like the above with git-svnimport\nfor memory-starved setups.\n\n-- \nEric Wong\n"},{"id":"17917","messageId":"m31wwqritj.fsf@lugabout.jhcloos.org","threadId":"3698","inReplyTo":"20060322133337.GU20746@lug-owl.de","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2006-03-25T09:10:16Z","receivedAt":"2006-03-25T09:10:16Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":"Isn't gcc in svn nowadays?\n\nI'd try something like:\n\nrsync://gcc.gnu.org/gcc-svn gcc-svn\ngit-svnimport -C gcc-git -i -v file:///$(pwd)/gcc-svn\n\nunless you have write access, in which case you may prefer:\n\nmkdir gcc-svn && cd gcc-svn\ngit-svn init svn+ssh://username@gcc.gnu.org/svn/gcc/trunk\ngit-svn fetch\n\n-JimC\n-- \nJames H. Cloos, Jr. \n"},{"id":"17923","messageId":"20060325101721.GJ31387@lug-owl.de","threadId":"3698","inReplyTo":"4424443F.5090209@op5.se","subject":"Re: Errors GITtifying GCC and Binutils","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-03-25T10:17:21Z","receivedAt":"2006-03-25T10:17:21Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Fri, 2006-03-24 20:10:55 +0100, Andreas Ericsson wrote:\n> Jan-Benedict Glaw wrote:\n> >On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw \n> >wrote:\n> >\n> >Since it seems nobody looked at the GCC import run (which means to use\n> >the svnimport), I ran it again, under strace control:\n> \n> If you send me a bzipped tar-ball of the repo you're trying to import, \n> preferrably with all the patches to cvsps you've tried, I'll see what I \n> can do over the weekend.\n\nIt's the regular SVN-based sources of GCC at their upstream location.\nIn their CVS timeline, they had the repository rsync'able, but I guess\nwith SVN we only get access through the SVN server.\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _\n\"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O\n für einen Freien Staat voll Freier Bürger\" | im Internet! | im Irak! O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"17973","messageId":"11433415513822-git-send-email-normalperson@yhbt.net","threadId":"3698","inReplyTo":"20060325082521.GA17473@hand.yhbt.net","subject":"[PATCH] contrib/git-svn: stabilize memory usage for big fetches","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-03-26T02:52:31Z","receivedAt":"2006-03-26T02:52:31Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"We should be safely able to import histories with thousands\nof revisions without hogging up lots of memory.\n\nWith this, we lose the ability to autocorrect mistakes when\npeople specify revisions in reverse, but it's probably no longer\na problem since we only have one method of log parsing nowadays.\n\nI've added an extra check to ensure that revision numbers do\nincrement.\n\nAlso, increment the version number to 0.11.0. I really should\njust call it 1.0 soon...\n\nSigned-off-by: Eric Wong \n\n---\n\n contrib/git-svn/git-svn.perl | 109 ++++++++++++++++++++++++------------------\n 1 files changed, 63 insertions(+), 46 deletions(-)\n\nc76df6617116a7d330a3110230bc3b01eaf9c66d\ndiff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl\nindex f3fc3ec..3e5733e 100755\n--- a/contrib/git-svn/git-svn.perl\n+++ b/contrib/git-svn/git-svn.perl\n@@ -8,7 +8,7 @@ use vars qw/\t$AUTHOR $VERSION\n \t\t$GIT_SVN_INDEX $GIT_SVN\n \t\t$GIT_DIR $REV_DIR/;\n $AUTHOR = 'Eric Wong ';\n-$VERSION = '0.10.0';\n+$VERSION = '0.11.0';\n $GIT_DIR = $ENV{GIT_DIR} || \"$ENV{PWD}/.git\";\n # make sure the svn binary gives consistent output between locales and TZs:\n $ENV{TZ} = 'UTC';\n@@ -217,9 +217,8 @@ sub fetch {\n \tpush @log_args, '--stop-on-copy' unless $_no_stop_copy;\n \n \tmy $svn_log = svn_log_raw(@log_args);\n-\t@$svn_log = sort { $a->{revision} <=> $b->{revision} } @$svn_log;\n \n-\tmy $base = shift @$svn_log or croak \"No base revision!\\n\";\n+\tmy $base = next_log_entry($svn_log) or croak \"No base revision!\\n\";\n \tmy $last_commit = undef;\n \tunless (-d $SVN_WC) {\n \t\tsvn_cmd_checkout($SVN_URL,$base->{revision},$SVN_WC);\n@@ -234,18 +233,22 @@ sub fetch {\n \t}\n \tmy @svn_up = qw(svn up);\n \tpush @svn_up, '--ignore-externals' unless $_no_ignore_ext;\n-\tmy $last_rev = $base->{revision};\n-\tforeach my $log_msg (@$svn_log) {\n-\t\tassert_svn_wc_clean($last_rev, $last_commit);\n-\t\t$last_rev = $log_msg->{revision};\n-\t\tsys(@svn_up,\"-r$last_rev\");\n+\tmy $last = $base;\n+\twhile (my $log_msg = next_log_entry($svn_log)) {\n+\t\tassert_svn_wc_clean($last->{revision}, $last_commit);\n+\t\tif ($last->{revision} >= $log_msg->{revision}) {\n+\t\t\tcroak \"Out of order: last >= current: \",\n+\t\t\t\t\"$last->{revision} >= $log_msg->{revision}\\n\";\n+\t\t}\n+\t\tsys(@svn_up,\"-r$log_msg->{revision}\");\n \t\t$last_commit = git_commit($log_msg, $last_commit, @parents);\n+\t\t$last = $log_msg;\n \t}\n-\tassert_svn_wc_clean($last_rev, $last_commit);\n+\tassert_svn_wc_clean($last->{revision}, $last_commit);\n \tunless (-e \"$GIT_DIR/refs/heads/master\") {\n \t\tsys(qw(git-update-ref refs/heads/master),$last_commit);\n \t}\n-\treturn pop @$svn_log;\n+\treturn $last;\n }\n \n sub commit {\n@@ -708,49 +711,61 @@ sub svn_commit_tree {\n \treturn fetch(\"$rev_committed=$commit\")->{revision};\n }\n \n+# read the entire log into a temporary file (which is removed ASAP)\n+# and store the file handle + parser state\n sub svn_log_raw {\n \tmy (@log_args) = @_;\n-\tmy $pid = open my $log_fh,'-|';\n+\tmy $log_fh = IO::File->new_tmpfile or croak $!;\n+\tmy $pid = fork;\n \tdefined $pid or croak $!;\n-\n-\tif ($pid == 0) {\n+\tif (!$pid) {\n+\t\topen STDOUT, '>&', $log_fh or croak $!;\n \t\texec (qw(svn log), @log_args) or croak $!\n \t}\n+\twaitpid $pid, 0;\n+\tcroak if $?;\n+\tseek $log_fh, 0, 0 or croak $!;\n+\treturn { state => 'sep', fh => $log_fh };\n+}\n+\n+sub next_log_entry {\n+\tmy $log = shift; # retval of svn_log_raw()\n+\tmy $ret = undef;\n+\tmy $fh = $log->{fh};\n \n-\tmy @svn_log;\n-\tmy $state = 'sep';\n-\twhile (<$log_fh>) {\n+\twhile (<$fh>) {\n \t\tchomp;\n \t\tif (/^\\-{72}$/) {\n-\t\t\tif ($state eq 'msg') {\n-\t\t\t\tif ($svn_log[$#svn_log]->{lines}) {\n-\t\t\t\t\t$svn_log[$#svn_log]->{msg} .= $_.\"\\n\";\n-\t\t\t\t\tunless(--$svn_log[$#svn_log]->{lines}) {\n-\t\t\t\t\t\t$state = 'sep';\n+\t\t\tif ($log->{state} eq 'msg') {\n+\t\t\t\tif ($ret->{lines}) {\n+\t\t\t\t\t$ret->{msg} .= $_.\"\\n\";\n+\t\t\t\t\tunless(--$ret->{lines}) {\n+\t\t\t\t\t\t$log->{state} = 'sep';\n \t\t\t\t\t}\n \t\t\t\t} else {\n \t\t\t\t\tcroak \"Log parse error at: $_\\n\",\n-\t\t\t\t\t\t$svn_log[$#svn_log]->{revision},\n+\t\t\t\t\t\t$ret->{revision},\n \t\t\t\t\t\t\"\\n\";\n \t\t\t\t}\n \t\t\t\tnext;\n \t\t\t}\n-\t\t\tif ($state ne 'sep') {\n+\t\t\tif ($log->{state} ne 'sep') {\n \t\t\t\tcroak \"Log parse error at: $_\\n\",\n-\t\t\t\t\t\"state: $state\\n\",\n-\t\t\t\t\t$svn_log[$#svn_log]->{revision},\n+\t\t\t\t\t\"state: $log->{state}\\n\",\n+\t\t\t\t\t$ret->{revision},\n \t\t\t\t\t\"\\n\";\n \t\t\t}\n-\t\t\t$state = 'rev';\n+\t\t\t$log->{state} = 'rev';\n \n \t\t\t# if we have an empty log message, put something there:\n-\t\t\tif (@svn_log) {\n-\t\t\t\t$svn_log[$#svn_log]->{msg} ||= \"\\n\";\n-\t\t\t\tdelete $svn_log[$#svn_log]->{lines};\n+\t\t\tif ($ret) {\n+\t\t\t\t$ret->{msg} ||= \"\\n\";\n+\t\t\t\tdelete $ret->{lines};\n+\t\t\t\treturn $ret;\n \t\t\t}\n \t\t\tnext;\n \t\t}\n-\t\tif ($state eq 'rev' && s/^r(\\d+)\\s*\\|\\s*//) {\n+\t\tif ($log->{state} eq 'rev' && s/^r(\\d+)\\s*\\|\\s*//) {\n \t\t\tmy $rev = $1;\n \t\t\tmy ($author, $date, $lines) = split(/\\s*\\|\\s*/, $_, 3);\n \t\t\t($lines) = ($lines =~ /(\\d+)/);\n@@ -758,36 +773,34 @@ sub svn_log_raw {\n \t\t\t\t\t/(\\d{4})\\-(\\d\\d)\\-(\\d\\d)\\s\n \t\t\t\t\t (\\d\\d)\\:(\\d\\d)\\:(\\d\\d)\\s([\\-\\+]\\d+)/x)\n \t\t\t\t\t or croak \"Failed to parse date: $date\\n\";\n-\t\t\tmy %log_msg = (\trevision => $rev,\n+\t\t\t$ret = {\trevision => $rev,\n \t\t\t\t\tdate => \"$tz $Y-$m-$d $H:$M:$S\",\n \t\t\t\t\tauthor => $author,\n \t\t\t\t\tlines => $lines,\n-\t\t\t\t\tmsg => '' );\n+\t\t\t\t\tmsg => '' };\n \t\t\tif (defined $_authors && ! defined $users{$author}) {\n \t\t\t\tdie \"Author: $author not defined in \",\n \t\t\t\t\t\t\"$_authors file\\n\";\n \t\t\t}\n-\t\t\tpush @svn_log, \\%log_msg;\n-\t\t\t$state = 'msg_start';\n+\t\t\t$log->{state} = 'msg_start';\n \t\t\tnext;\n \t\t}\n \t\t# skip the first blank line of the message:\n-\t\tif ($state eq 'msg_start' && /^$/) {\n-\t\t\t$state = 'msg';\n-\t\t} elsif ($state eq 'msg') {\n-\t\t\tif ($svn_log[$#svn_log]->{lines}) {\n-\t\t\t\t$svn_log[$#svn_log]->{msg} .= $_.\"\\n\";\n-\t\t\t\tunless (--$svn_log[$#svn_log]->{lines}) {\n-\t\t\t\t\t$state = 'sep';\n+\t\tif ($log->{state} eq 'msg_start' && /^$/) {\n+\t\t\t$log->{state} = 'msg';\n+\t\t} elsif ($log->{state} eq 'msg') {\n+\t\t\tif ($ret->{lines}) {\n+\t\t\t\t$ret->{msg} .= $_.\"\\n\";\n+\t\t\t\tunless (--$ret->{lines}) {\n+\t\t\t\t\t$log->{state} = 'sep';\n \t\t\t\t}\n \t\t\t} else {\n \t\t\t\tcroak \"Log parse error at: $_\\n\",\n-\t\t\t\t\t$svn_log[$#svn_log]->{revision},\"\\n\";\n+\t\t\t\t\t$ret->{revision},\"\\n\";\n \t\t\t}\n \t\t}\n \t}\n-\tclose $log_fh or croak $?;\n-\treturn \\@svn_log;\n+\treturn $ret;\n }\n \n sub svn_info {\n@@ -1114,9 +1127,13 @@ __END__\n \n Data structures:\n \n-@svn_log = array of log_msg hashes\n+$svn_log hashref (as returned by svn_log_raw)\n+{\n+\tfh => file handle of the log file,\n+\tstate => state of the log file parser (sep/msg/rev/msg_start...)\n+}\n \n-$log_msg hash\n+$log_msg hashref as returned by next_log_entry($svn_log)\n {\n \tmsg => 'whitespace-formatted log entry\n ',\t\t\t\t\t\t# trailing newline is preserved\n-- \n1.2.4.gb622a\n"}]}