{"thread":{"id":"4223","subject":"synchronizing incremental git changes to cvs","startedAt":"2006-05-20T22:13:25Z","lastAt":"2006-05-22T17:05:25Z","messageCount":20,"participants":["Jim Meyering","Johannes Schindelin","Martin Langhoff","Junio C Hamano","Jakub Narebski","Morten Welinder","Jeff King","Pavel Roskin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20341","messageId":"87mzdcjqey.fsf@rho.meyering.net","threadId":"4223","inReplyTo":null,"subject":"synchronizing incremental git changes to cvs","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-20T22:13:25Z","receivedAt":"2006-05-20T22:13:25Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Hello,\n\nCan anyone point me at code to mirror a git repository to cvs?\nI'd like to develop using git, and have a commit hook mirror the\nday-to-day changes (tags/commits) made in the git repo to a\ncvs repository. The idea is that the only way changes get into\nthe cvs repo is via the git commit hook.\n\nI've experimented with git-cvsexportcommit, and found a few bugs (it\ncouldn't handle simple things, like adding a file in a new directory --\nfixed that, along with a few other minor problems), adding an empty file\nin git still gets a patch application error on the cvs side, but I can\nlive with that for now. More seriously, making a change on a git branch\nmistakenly tries to apply the delta on the cvs trunk. None of this is\nparticularly hard to fix -- or even critical, as long as you don't care\nabout branches. I'm just hoping someone has already produced something\nmore robust. From the looks of darcs/tailor, it doesn't handle the use\nof git as a source.\n\nWhy am I interested? I want to switch the development of GNU coreutils\nfrom cvs to git. I would also like to continue making the repository\navailable via cvs, for the sake of continuity. At worst, I can always\ncut the CVS cord, but that's a last resort.\n\nJim\n"},{"id":"20348","messageId":"Pine.LNX.4.63.0605210104470.3148@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4223","inReplyTo":"87mzdcjqey.fsf@rho.meyering.net","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-20T23:05:46Z","receivedAt":"2006-05-20T23:05:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 May 2006, Jim Meyering wrote:\n\n> Why am I interested? I want to switch the development of GNU coreutils\n> from cvs to git. I would also like to continue making the repository\n> available via cvs, for the sake of continuity. At worst, I can always\n> cut the CVS cord, but that's a last resort.\n\nIf you only want to make a cvs repository available for tracking the \nproject, git-cvsserver is what you want. It is even faster than the \noriginal cvs...\n\nCiao,\nDscho\n"},{"id":"20353","messageId":"46a038f90605201709n3a840fd9n7e85a289f49a3c5f@mail.gmail.com","threadId":"4223","inReplyTo":"87mzdcjqey.fsf@rho.meyering.net","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-05-21T00:09:19Z","receivedAt":"2006-05-21T00:09:19Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/21/06, Jim Meyering wrote:\n> Can anyone point me at code to mirror a git repository to cvs?\n\nIve thought a couple of times about writing an exporter that would\nreplay things into a true CVS repo, but it's truly not worth it. We've\nalready got git-cvsserver that does all that -- better for me to focus\non that codebase.\n\n> I've experimented with git-cvsexportcommit, and found a few bugs (it\n> couldn't handle simple things, like adding a file in a new directory --\n> fixed that, along with a few other minor problems), adding an empty file\n> in git still gets a patch application error on the cvs side, but I can\n> live with that for now. More seriously, making a change on a git branch\n> mistakenly tries to apply the delta on the cvs trunk.\n\ncvsexportcommit is clearly for manual usage, not for automagic usage.\nIt is a bit rough, (and I'd like to see your patches to it!) but it\nwants to be driven by a smarter script to, for instance, know what\nbranch you want things in.\n\n> Why am I interested? I want to switch the development of GNU coreutils\n> from cvs to git. I would also like to continue making the repository\n> available via cvs, for the sake of continuity. At worst, I can always\n> cut the CVS cord, but that's a last resort.\n\ngit-cvsserver is the word. It currently tracks the git repo itself\npretty well (perfectly, AFAICS) and it also tracks a git tree that is\nactually imported daily from CVS -- doing\n\n CVSrepo ->cvsimport -> GIT -> cvsserver -> CVS checkout\n\ngit-cvsserver works great for anon cvs access (does pserver) and\nTortoiseCVS and cli cvs work great with it. Eclipse works well, but it\nhas been quite hard to get 'right'. Optionally, it can support users\nwith commit rights via ssh. It does track git 'heads' but they don't\nshow up as branches, they show up as different modules. So you to get\na checkout of the master branch, you do:\n\n cvs -d pserver:anonymouys@foo.com:/var/foo.git co master\n\nhope that helps!\n\n\n\n\nmartin\n"},{"id":"20393","messageId":"873bf3jy2t.fsf@rho.meyering.net","threadId":"4223","inReplyTo":"Pine.LNX.4.63.0605210104470.3148@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-21T13:40:10Z","receivedAt":"2006-05-21T13:40:10Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Johannes Schindelin wrote:\n> On Sun, 21 May 2006, Jim Meyering wrote:\n>\n>> Why am I interested? I want to switch the development of GNU coreutils\n>> from cvs to git. I would also like to continue making the repository\n>> available via cvs, for the sake of continuity. At worst, I can always\n>> cut the CVS cord, but that's a last resort.\n>\n> If you only want to make a cvs repository available for tracking the\n> project, git-cvsserver is what you want. It is even faster than the\n> original cvs...\n\nThat might work if I had sufficient access to the system hosting the\npublic CVS repository. But there are restrictions (like no ssh access).\nCurrently I rsync the master repo to an intermediate site, from which\nit is periodically pulled by savannah. Paranoia on both sides.\n\nIf I end up leaving savannah, can someone propose a good site,\ni.e., secure, yet with git and rsync access?\n\nI haven't made the leap to git yet, but git-cvsimport (from git-1.3.2)\nseems to do a very good job of converting the cvs module (89MB).\n\nFYI, here are some stats on the resulting git repository:\n\nSize (nothing repacked):\n 1051MB (du -sh, actual, on reiserfs 3)\n 708MB (du --apparent-size)\n\nSize repacked, (via git-repack -a -d && git-prune-packed)\n 65MB (du --si -s)\n\n20k+ patchsets (counted by cvsps)\n40k+ revisions (counted by cvs ... rlog cu|grep -c '^revision')\n\nWhile repacking, git said something about more than 100K objects.\nThere were 120K files under .git/ before repacking.\n"},{"id":"20397","messageId":"87r72niba4.fsf@rho.meyering.net","threadId":"4223","inReplyTo":"46a038f90605201709n3a840fd9n7e85a289f49a3c5f@mail.gmail.com","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-21T16:37:55Z","receivedAt":"2006-05-21T16:37:55Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"\"Martin Langhoff\" wrote:\n> git-cvsserver is the word. It currently tracks the git repo itself\n> pretty well (perfectly, AFAICS) and it also tracks a git tree that is\n> actually imported daily from CVS -- doing\n>\n> CVSrepo ->cvsimport -> GIT -> cvsserver -> CVS checkout\n\nThanks, but I'd rather do primary development directly using git,\nrather than with CVS.\n"},{"id":"20399","messageId":"7v3bf3jl15.fsf@assigned-by-dhcp.cox.net","threadId":"4223","inReplyTo":"87mzdcjqey.fsf@rho.meyering.net","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-21T18:21:58Z","receivedAt":"2006-05-21T18:21:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jim Meyering writes:\n\n> I'd like to develop using git, and have a commit hook mirror the\n> day-to-day changes (tags/commits) made in the git repo to a\n> cvs repository. The idea is that the only way changes get into\n> the cvs repo is via the git commit hook.\n\nI do not use the automated tools myself, but I sync the day-job\nwork in my git repository to CVS at work. I do not develop with\nCVS but use it merely as a publishing medium. Although other\npeople can make commits into CVS in which case I have to slurp\nthe change back into my git repository.\n\n (0) Bootstrap. I did use git-cvsimport myself (this repository\n started before the tool was written). Instead:\n\n . cvs checkout the tip of the CVS development history\n\n . \"git init-db\", edit .gitignore to ignore CVS, and \"git\n add .\"\n\n . \"git commit -m epoch\"; the git side of development\n history in this repository starts at that point for me. \n\n . \"git branch origin\"; the tip of CVS repository is kept\n track of with this branch. I work in \"master\".\n\n I think I could have done the above with git-cvsimport,\n\n (1) Beginning of the day. In case other people did work on\n the CVS side, I do this:\n\n . \"git checkout origin\", \"cvs -q update\". If there is no\n change, go to step (3).\n\n . add any new files with \"git add\", and update the \"origin\"\n branch with \"git commit -a -m 'from CVS'\".\n\n (2) Merge other's work into my git master branch.\n\n . \"git checkout master\" and \"git pull . cvs\"; conflict\n resolve as needed.\n\n (3) Do my work.\n\n . \"git checkout master\" if I haven't done so. \n\n . hack away, grow \"master\" branch using full power of git\n including the use of topic branches etc.\n\n (4) Publish, when \"master\" changes are ready.\n\n . To avoid conflicts with other people working on CVS,\n perform (1) again to make sure \"origin\" matches the tip\n of CVS.\n\n . \"git checkout origin\", \"git pull . master\".\n\n . generate the consolidated log I am about to push back to\n CVS with \"git log --no-merges ORIG_HEAD.. | git shortlog >L\".\n\n . add any new files with \"cvs add\", and \"cvs commit -F L\"\n\n . go back to (3) and continue.\n\nThis can be extended to multiple CVS branches. Per one CVS\nbranch, use one git branch to track its head (plays the role of\n\"origin\" in the above), use another to do the real development\nfor that branch (\"master\" in the above). Never use merges on\nthe CVS side, but perform merges on the git side and then\npushing the merge result back to CVS. This frees you from the\nnightmarish branch management.\n\nThe above obviously have advantages and disadvantages.\n\n . I do not use any git import tool, so in theory you can apply\n this to _any_ foreign SCM.\n\n . I treat the foreign SCM as a second class citizen; multiple\n commits made there are rolled into a single commit on the git\n side (the real project history as far as I am concerned),\n which may or may not be nice. The people who see my work\n through CVS see multiple commits on git side as a single\n commit in CVS.\n\nIn my situation this is fine as is, but I think you could leave\nthe management of \"origin\" to git-cvsimport (then your working\ntree would not have CVS metadirectories as the above outline\ndoes) if you wanted to avoid the \"rolled into one commit\" issue.\n\nPushing the changes on the git side back to CVS may become\ntrickier (and that is why I still keep the above setup without\nusing git-cvsimport), as I do not offhand know how exportcommit\nworks. The commits on the git side you would want to push back\nare the ones on \"master\" but not on \"origin\", which you can get\nfrom \"git rev-list origin..master\", so I presume if you feed\nthat to exportcommit things all magically work?\n\nBy the way, I met Paul a few days ago and he mentioned that you\nhave some quick audit results on our code from your evaluation.\nCan we expect fixes or at least pointing-out-problems from you\nsometime soon please?\n"},{"id":"20404","messageId":"87irnzhxo2.fsf@rho.meyering.net","threadId":"4223","inReplyTo":"7v3bf3jl15.fsf@assigned-by-dhcp.cox.net","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-21T21:31:57Z","receivedAt":"2006-05-21T21:31:57Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Junio C Hamano wrote:\n> Jim Meyering writes:\n>> I'd like to develop using git, and have a commit hook mirror the\n>> day-to-day changes (tags/commits) made in the git repo to a\n>> cvs repository. The idea is that the only way changes get into\n>> the cvs repo is via the git commit hook.\n>\n> I do not use the automated tools myself, but I sync the day-job\n> work in my git repository to CVS at work. I do not develop with\n> CVS but use it merely as a publishing medium. Although other\n> people can make commits into CVS in which case I have to slurp\n> the change back into my git repository.\n>\n> (0) Bootstrap. I did use git-cvsimport myself (this repository\n...\n> (1) Beginning of the day. In case other people did work on\n...\n\nThank you for describing the process you use.\nHowever, since I don't have to allow independent cvs commits,\nI hope to bend git-cvsexportcommit to my needs.\nIt already does almost everything I want.\n\n> using git-cvsimport), as I do not offhand know how exportcommit\n> works. The commits on the git side you would want to push back\n> are the ones on \"master\" but not on \"origin\", which you can get\n> from \"git rev-list origin..master\", so I presume if you feed\n> that to exportcommit things all magically work?\n\nI haven't yet tried to restrict the mirroring to commits on a specific\ngit branch. So far, in the toy example I'm using to test things,\nI have this in .git/hooks/post-commit:\n\n#!/bin/sh\nsha1_id=$(git-rev-parse --verify HEAD)\ncvsdir=/var/tmp/work-c\ncd $cvsdir && GIT_DIR=/var/tmp/git-experiment/work-g/.git \\\n git-cvsexportcommit -v -c -p $sha1_id\n\nI'll clean up and post the changes I've made to git-cvsexportcommit\nthis week.\n\n> By the way, I met Paul a few days ago and he mentioned that you\n> have some quick audit results on our code from your evaluation.\n> Can we expect fixes or at least pointing-out-problems from you\n> sometime soon please?\n\nI'll send one report separately.\n"},{"id":"20405","messageId":"87d5e7hxhl.fsf_-_@rho.meyering.net","threadId":"4223","inReplyTo":"7v3bf3jl15.fsf@assigned-by-dhcp.cox.net","subject":"don't accept bogus N in `HEAD~N'","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-21T21:35:50Z","receivedAt":"2006-05-21T21:35:50Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"In a very shallow audit, I spotted code where overflow was not detected.\nBut it's hardly critical.\n\nCurrently,\n\n git-diff HEAD HEAD\n\nis equivalent to this\n\n git-diff HEAD HEAD~18446744073709551616 # aka 2^64\n\nExercising git-rev-parse directly, currently I get this:\n\n $ git-rev-parse --no-flags --sq HEAD~18446744073709551616\n '639ca5497279607665847f2e3a11064441a8f2a6'\n\nIt'd be better to produce a diagnostic and fail:\n\n $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 > /dev/null\n fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename\n\nThe code in question is in sha1_name.c (get_sha1_1):\n\n int num = 0;\n ...\n while (cp < name + len)\n num = num * 10 + *cp++ - '0';\n\nLooking at how to fix it, my first reflex was to replace that loop\nwith this one:\n\n\t\twhile (cp < name + len) {\n\t\t\tint tmp = num * 10 + *cp++ - '0';\n\t\t\tif (INT_MAX / 10 < num || tmp < num)\n\t\t\t\treturn -1;\n\t\t\tnum = tmp;\n\t\t}\n\nBut INT_MAX is used nowhere else, so I wonder if git avoids using\nit for some reason. At least `make check' gripes about __INT_MAX__.\nAnyhow, here's the patch I used. With it, git still passes `make test'.\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex dc68355..c813ba0 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -429,8 +429,12 @@ static int get_sha1_1(const char *name,\n \t\tint num = 0;\n \t\tint len1 = cp - name;\n \t\tcp++;\n-\t\twhile (cp < name + len)\n-\t\t\tnum = num * 10 + *cp++ - '0';\n+\t\twhile (cp < name + len) {\n+\t\t\tint tmp = num * 10 + *cp++ - '0';\n+\t\t\tif (INT_MAX / 10 < num || tmp < num)\n+\t\t\t\treturn -1;\n+\t\t\tnum = tmp;\n+\t\t}\n \t\tif (has_suffix == '^') {\n \t\t\tif (!num && len1 == len - 1)\n \t\t\t\tnum = 1;\n"},{"id":"20407","messageId":"e4qmsn$3mv$1@sea.gmane.org","threadId":"4223","inReplyTo":"87d5e7hxhl.fsf_-_@rho.meyering.net","subject":"Re: don't accept bogus N in `HEAD~N'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-21T21:42:47Z","receivedAt":"2006-05-21T21:42:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jim Meyering wrote:\n\n> In a very shallow audit, I spotted code where overflow was not detected.\n> But it's hardly critical.\n> \n> Currently,\n> \n> git-diff HEAD HEAD\n> \n> is equivalent to this\n> \n> git-diff HEAD HEAD~18446744073709551616 # aka 2^64\n> \n> Exercising git-rev-parse directly, currently I get this:\n> \n> $ git-rev-parse --no-flags --sq HEAD~18446744073709551616\n> '639ca5497279607665847f2e3a11064441a8f2a6'\n> \n> It'd be better to produce a diagnostic and fail:\n> \n> $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 /dev/null\n> fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename\n\nWouldn't it remove ability to say \"to the root commit\"?\nOne can do it now I guess exactly by specyfying overly large N.\nAlthough there should probably be some limit... or not.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"20427","messageId":"871wumim28.fsf_-_@rho.meyering.net","threadId":"4223","inReplyTo":"7v3bf3jl15.fsf@assigned-by-dhcp.cox.net","subject":"avoid atoi, when possible; int overflow -> heap corruption","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-22T06:57:19Z","receivedAt":"2006-05-22T06:57:19Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"This is another one of those `would be nice' sort of changes.\nProbably not worth much at this early stage in development, but\neventually worth changing.\n\nThere are about 20 uses of atoi, and most calls can return\na usable result in spite of an invalid input -- just because\natoi returns the same thing for \"99\" as \"99-and-any-suffix\".\nIt would be better not to ignore invalid inputs.\n\n-------------------\nAlso, integer overflow in object.c can cause trouble.\nWhen the xrealloc byte count exceeds 2^32 (for a 32-bit int),\nxrealloc will happily return a buffer of the requested (small) size,\nbut the following memset will scribble zeroes far beyond the end\nof that new buffer.\n\nstatic int nr_objs;\nint obj_allocs;\n...\nvoid created_object(const unsigned char *sha1, struct object *obj)\n{\n...\n\tif (obj_allocs - 1 <= nr_objs * 2) {\n\t\tint i, count = obj_allocs;\n\t\tobj_allocs = (obj_allocs < 32 ? 32 : 2 * obj_allocs);\n\t\tobjs = xrealloc(objs, obj_allocs * sizeof(struct object *));\n\t\tmemset(objs + count, 0, (obj_allocs - count)\n\t\t\t\t* sizeof(struct object *));\n\nBut this may be only theoretical, because the problem doesn't strike\nuntil there are over 250M objects (assuming 32-bit int and 8-byte pointers).\n"},{"id":"20428","messageId":"87psi6h5kv.fsf@rho.meyering.net","threadId":"4223","inReplyTo":"e4qmsn$3mv$1@sea.gmane.org","subject":"Re: don't accept bogus N in `HEAD~N'","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-22T07:38:40Z","receivedAt":"2006-05-22T07:38:40Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Jakub Narebski wrote:\n\n> Jim Meyering wrote:\n>\n>> In a very shallow audit, I spotted code where overflow was not detected.\n>> But it's hardly critical.\n>>\n>> Currently,\n>>\n>> git-diff HEAD HEAD\n>>\n>> is equivalent to this\n>>\n>> git-diff HEAD HEAD~18446744073709551616 # aka 2^64\n>>\n>> Exercising git-rev-parse directly, currently I get this:\n>>\n>> $ git-rev-parse --no-flags --sq HEAD~18446744073709551616\n>> '639ca5497279607665847f2e3a11064441a8f2a6'\n>>\n>> It'd be better to produce a diagnostic and fail:\n>>\n>> $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 /dev/null\n>> fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename\n>\n> Wouldn't it remove ability to say \"to the root commit\"?\n> One can do it now I guess exactly by specyfying overly large N.\n> Although there should probably be some limit... or not.\n\nDo people really use HEAD~ to refer to the root?\nAny who do that will find it surprising that HEAD~18446744073709551616\nis currently interpreted just like `HEAD~0'.\nAnd HEAD~18446744073709551617 just like HEAD~1, etc.\n"},{"id":"20430","messageId":"7vr72meapg.fsf@assigned-by-dhcp.cox.net","threadId":"4223","inReplyTo":"87psi6h5kv.fsf@rho.meyering.net","subject":"Re: don't accept bogus N in `HEAD~N'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-22T08:16:11Z","receivedAt":"2006-05-22T08:16:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jim Meyering writes:\n\n> Jakub Narebski wrote:\n>\n>> Jim Meyering wrote:\n>>\n>>> It'd be better to produce a diagnostic and fail:\n\nI agree with you that we are loose in integer overlaps. Some of\nthem do matter, some don't. The xrealloc one is, as you said,\nborderline, I think, but more serious than this one. This one\nis worth fixing only if/because the fix is obvious and does not\nhurt the code otherwise (e.g. does not decrease portability,\ndoes not hurt usability, etc.).\n\n>>>\n>>> $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 /dev/null\n>>> fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename\n>>\n>> Wouldn't it remove ability to say \"to the root commit\"?\n>> One can do it now I guess exactly by specyfying overly large N.\n>> Although there should probably be some limit... or not.\n>\n> Do people really use HEAD~ to refer to the root?\n\nYou shouldn't have to care about nor refer to the root commit\nthat often (if ever) in a real project. It is handy to be able\nto refer to it when your repository is very young and you are\ntoying with git more than you are working on your own project\nthat is managed by git. But in such a case, finding it once and\ntagging it is so easy and efficient that you would not want to\ntraverse the whole history every time you would want to refer to\nit.\n\nIn other words, I think Jakub was just joking, and this\nparticular objection does not qualify as \"hurt usability\"\ncriteria I said in the above.\n"},{"id":"20432","messageId":"7vmzdaeaab.fsf@assigned-by-dhcp.cox.net","threadId":"4223","inReplyTo":"7vr72meapg.fsf@assigned-by-dhcp.cox.net","subject":"Re: don't accept bogus N in `HEAD~N'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-22T08:25:16Z","receivedAt":"2006-05-22T08:25:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jim Meyering writes:\n>\n>> Jakub Narebski wrote:\n>>\n>>> Jim Meyering wrote:\n>>>\n>>>> It'd be better to produce a diagnostic and fail:\n>\n> I agree with you that we are loose in integer overlaps. Some of\n\nOops; I meant overflow or wraparound.. Late night typo/thinko X-<. \n"},{"id":"20440","messageId":"87d5e6gxr0.fsf_-_@rho.meyering.net","threadId":"4223","inReplyTo":"7v3bf3jl15.fsf@assigned-by-dhcp.cox.net","subject":"detect write failure, even for stdout","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-22T10:27:47Z","receivedAt":"2006-05-22T10:27:47Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"git doesn't always detect write failures. A write I/O error,\n(e.g., hardware I/O error or simply disk full)\ndoesn't provoke nonzero exit status:\n\n $ ./git-cat-file -t HEAD > /dev/full && echo did not detect write failure\n did not detect write failure\n\nThis is perhaps more important than the other things\nI've reported, since it can lead to porcelain being unable\nto detect a real failure in the plumbing.\n\nHere are two more:\n\n $ ./git-ls-tree HEAD > /dev/full && echo fail\n fail\n $ ./git-show > /dev/full && echo fail\n fail\n\nIf you were using gnulib, I'd suggest simply adding this line\n\n atexit (close_stdout);\n\nnear the beginning of each `main'. Then you wouldn't have to\nmanually track down each and every place where a write to stdout\ncan occur -- not to mention the maintenance burden of keeping\nthings correct as the code evolves.\n"},{"id":"20446","messageId":"118833cc0605220616t75a182b1oa404d5efe8a1f5d9@mail.gmail.com","threadId":"4223","inReplyTo":"871wumim28.fsf_-_@rho.meyering.net","subject":"Re: avoid atoi, when possible; int overflow -> heap corruption","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2006-05-22T13:16:50Z","receivedAt":"2006-05-22T13:16:50Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"> There are about 20 uses of atoi, and most calls can return\n> a usable result in spite of an invalid input -- just because\n> atoi returns the same thing for \"99\" as \"99-and-any-suffix\".\n> It would be better not to ignore invalid inputs.\n\natoi has undefined behaviour for \"99-and-any-suffix\". You might\nget lucky and get back 99, but you might also get a random value\nor a core dump.\n\nMorten\n"},{"id":"20447","messageId":"878xoufaof.fsf@rho.meyering.net","threadId":"4223","inReplyTo":"118833cc0605220616t75a182b1oa404d5efe8a1f5d9@mail.gmail.com","subject":"Re: avoid atoi, when possible; int overflow -> heap corruption","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2006-05-22T13:31:28Z","receivedAt":"2006-05-22T13:31:28Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"\"Morten Welinder\" wrote:\n>> There are about 20 uses of atoi, and most calls can return\n>> a usable result in spite of an invalid input -- just because\n>> atoi returns the same thing for \"99\" as \"99-and-any-suffix\".\n>> It would be better not to ignore invalid inputs.\n>\n> atoi has undefined behaviour for \"99-and-any-suffix\". You might\n> get lucky and get back 99, but you might also get a random value\n> or a core dump.\n\nI've never heard of that.\nPOSIX says that atoi(str) is equivalent to:\n\n (int) strtol(str, (char **)NULL, 10)\n except that the handling of errors may differ.\n If the value cannot be represented, the behavior is undefined.\n\nSince strtol works fine with such a suffix, and since 99 can be\nrepresented, I don't see why there would be any undefined behavior.\n\nDo you know of an implementation for which `atoi (\"99-and-any-suffix\")'\ndoes anything other than return 99?\n"},{"id":"20448","messageId":"20060522133746.GA12302@coredump.intra.peff.net","threadId":"4223","inReplyTo":"118833cc0605220616t75a182b1oa404d5efe8a1f5d9@mail.gmail.com","subject":"Re: avoid atoi, when possible; int overflow -> heap corruption","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-05-22T13:37:46Z","receivedAt":"2006-05-22T13:37:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 22, 2006 at 09:16:50AM -0400, Morten Welinder wrote:\n\n> atoi has undefined behaviour for \"99-and-any-suffix\". You might\n> get lucky and get back 99, but you might also get a random value\n> or a core dump.\n\nWhere do you get that from? The standard claims that it converts \"the\ninitial portion of the string pointed to\" (7.20.1.2). Furthermore, atoi\nis equivalent to strtol with a base of 10 (with the exception of range\nerrors). From 7.20.1.4, paragraph 2:\n The strtol [...] functions [...] decompose the input string into three\n parts: an initial, possibly empty, sequence of white-space characters\n [...], a subject sequence resembling an integer represented in some\n radix determined by the value of base, and a final string of one or\n more unrecognized characters...\nIf no conversion can be performed (i.e., you feed it garbage with no\nnumber), zero is returned.\n\natoi does NOT handle range errors, however; the behavior is undefined in\nthat case. In practice, I expect most implementations do some sort of\nwrapping.\n\n-Peff\n"},{"id":"20449","messageId":"118833cc0605220654r51ce7764udab70c1ee89d9c3d@mail.gmail.com","threadId":"4223","inReplyTo":"20060522133746.GA12302@coredump.intra.peff.net","subject":"Re: avoid atoi, when possible; int overflow -> heap corruption","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2006-05-22T13:54:52Z","receivedAt":"2006-05-22T13:54:52Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"My copy (which is admittedly a draft because I am cheap) does not\nrestrict undefined behaviour to _range_ errors, but simply says\n\"Except for the behavior on error, they are equivalent to [the strtol call]\"\n\nM.\n"},{"id":"20456","messageId":"1148315362.29228.27.camel@dv","threadId":"4223","inReplyTo":"873bf3jy2t.fsf@rho.meyering.net","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-05-22T16:29:22Z","receivedAt":"2006-05-22T16:29:22Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Jim!\n\nOn Sun, 2006-05-21 at 15:40 +0200, Jim Meyering wrote:\n> Johannes Schindelin wrote:\n> > On Sun, 21 May 2006, Jim Meyering wrote:\n> >\n> >> Why am I interested? I want to switch the development of GNU coreutils\n> >> from cvs to git.\n\nI believe you have a very good reason to talk to decision makers in FSF.\nSavannah is very poorly maintained, and I actually took one of my\nprojects (Orinoco driver) to SourceForge Subversion.\n\nIf losing a Linux driver is next to nothing, losing GNU coreutils is a\nbig deal for the GNU development site. You are likely to be heard if\nyou request git support.\n\n> I would also like to continue making the repository\n> >> available via cvs, for the sake of continuity. At worst, I can always\n> >> cut the CVS cord, but that's a last resort.\n\nSubversion is as easy as CVS for potential users, but it has a useful\n\"log\" command if nothing else. It also have real changesets, which\nmeans no more guesswork when moving changes back and forth.\n\n> > If you only want to make a cvs repository available for tracking the\n> > project, git-cvsserver is what you want. It is even faster than the\n> > original cvs...\n> \n> That might work if I had sufficient access to the system hosting the\n> public CVS repository. But there are restrictions (like no ssh access).\n> Currently I rsync the master repo to an intermediate site, from which\n> it is periodically pulled by savannah. Paranoia on both sides.\n> \n> If I end up leaving savannah, can someone propose a good site,\n> i.e., secure, yet with git and rsync access?\n\nSorry, I don't know any free git hosters, but here's what you can do:\n\n1) Pressure Savannah to support git\n2) Use arch on Savannah\n3) Move to Subversion on SourceForge, GNA.org or Berlios and use git-svn\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"20457","messageId":"e4sr0h$dr3$1@sea.gmane.org","threadId":"4223","inReplyTo":"1148315362.29228.27.camel@dv","subject":"Re: synchronizing incremental git changes to cvs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-22T17:05:25Z","receivedAt":"2006-05-22T17:05:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Pavel Roskin wrote:\n\n> Sorry, I don't know any free git hosters, but here's what you can do:\n> \n> 1) Pressure Savannah to support git\n> 2) Use arch on Savannah\n> 3) Move to Subversion on SourceForge, GNA.org or Berlios and use git-svn\n\nI always thought that both Gna! and Savannah use Savane (SourceForge engine\nfork), which has CVS and Subversion support, and from what I can see also\nGNU Arch support. I'm quite sure that at Gna! you can choose between CVS,\nSVN and Arch.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"}]}