{"thread":{"id":"19547","subject":"exit status = 1 from git fetch -t","startedAt":"2009-05-28T03:57:07Z","lastAt":"2009-05-28T14:56:54Z","messageCount":3,"participants":["Villeneuve","Michael J Gruber","Villeneuve, Daniel"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"114876","messageId":"200905280357.n4S3v73G016535@hilo.ca.kronos.com","threadId":"19547","inReplyTo":null,"subject":"exit status = 1 from git fetch -t","fromName":"Villeneuve","fromEmail":"dvilleneuve@kronos.com","sentAt":"2009-05-28T03:57:07Z","receivedAt":"2009-05-28T03:57:07Z","isPatch":false,"sender":{"key":"dvilleneuve@kronos.com","avatar":null},"body":"Hi,\n\nI'm getting an unexpected exit status of 1 from \"git fetch\n-t\" on one of our largest repositories (by large, I mean 47\nbranches and 5442 tags, some of which might not be reachable\nfrom branch heads).\n\nThe docs are not clear about the interpretation of git\nfetch's exit status, so maybe I should not bother.\n\nBut assuming the exit status of 1 really indicates some\ntrouble, here are more details.\n\nNext tests done with git over ssh (server 1.6.1.3, client\n1.6.3.1) on RHEL4.\n\nIn the \"REPO1\" repository (exit status printed just before $\nin prompt following command):\n\n[REPO1] 0 $ git fetch -t -v -v\nServer supports multi_ack\nServer supports side-band-64k\nServer supports ofs-delta\nMarking 60e4d540748c5c3d368c888c4c248de0bdd684cc as complete\nMarking 60e4d540748c5c3d368c888c4c248de0bdd684cc as complete\n[REPO1] 1 $\n\nwhile with another repository, \"REPO2\":\n\n[REPO2] 0 $ git fetch -t -v -v\nFrom ssh://user@machine/path/to/GIT/dir1/dir2/REPO2\n = [up to date]      v1.1 -> v1.1\n = [up to date]      v1.2 -> v1.2\n = [up to date]      v2.0 -> v2.0\n... # lots of other similar lines\n[REPO2] 0 $\n\nI've compiled git in debug to step in the code, and the\nsource of the \"error\" exit status seems to come from\nbuiltin-fetch-pack.c:everything_local, where *refs being\nNULL leaves retval to 1 in the final loop.\n\nI'm also puzzled that I don't get the \"From ssh://...\" in\nthe trace from \"REPO1\" as for the \"REPO2\" repository above.\nI do get the \"From ssh://...\"  line if doing only \"git fetch\n-v -v\" without the \"-t\" option in \"REPO1\".\n\nAny help/advice appreciated,\n--\nDaniel Villeneuve\nKronos, AD OPT Division\n"},{"id":"114900","messageId":"4A1E43B1.20400@drmicha.warpmail.net","threadId":"19547","inReplyTo":"200905280357.n4S3v73G016535@hilo.ca.kronos.com","subject":"Re: exit status = 1 from git fetch -t","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-28T07:56:33Z","receivedAt":"2009-05-28T07:56:33Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Villeneuve venit, vidit, dixit 28.05.2009 05:57:\n> Hi,\n> \n> I'm getting an unexpected exit status of 1 from \"git fetch\n> -t\" on one of our largest repositories (by large, I mean 47\n> branches and 5442 tags, some of which might not be reachable\n> from branch heads).\n> \n> The docs are not clear about the interpretation of git\n> fetch's exit status, so maybe I should not bother.\n> \n> But assuming the exit status of 1 really indicates some\n> trouble, here are more details.\n> \n> Next tests done with git over ssh (server 1.6.1.3, client\n> 1.6.3.1) on RHEL4.\n> \n> In the \"REPO1\" repository (exit status printed just before $\n> in prompt following command):\n> \n> [REPO1] 0 $ git fetch -t -v -v\n> Server supports multi_ack\n> Server supports side-band-64k\n> Server supports ofs-delta\n> Marking 60e4d540748c5c3d368c888c4c248de0bdd684cc as complete\n> Marking 60e4d540748c5c3d368c888c4c248de0bdd684cc as complete\n> [REPO1] 1 $\n> \n> while with another repository, \"REPO2\":\n> \n> [REPO2] 0 $ git fetch -t -v -v\n> From ssh://user@machine/path/to/GIT/dir1/dir2/REPO2\n>  = [up to date]      v1.1 -> v1.1\n>  = [up to date]      v1.2 -> v1.2\n>  = [up to date]      v2.0 -> v2.0\n> ... # lots of other similar lines\n> [REPO2] 0 $\n> \n> I've compiled git in debug to step in the code, and the\n> source of the \"error\" exit status seems to come from\n> builtin-fetch-pack.c:everything_local, where *refs being\n> NULL leaves retval to 1 in the final loop.\n> \n> I'm also puzzled that I don't get the \"From ssh://...\" in\n> the trace from \"REPO1\" as for the \"REPO2\" repository above.\n> I do get the \"From ssh://...\"  line if doing only \"git fetch\n> -v -v\" without the \"-t\" option in \"REPO1\".\n\nLooking at that loop, I reckon everything_local() returns 0 if there is\nat least one object we \"want\" from the remote and 1 if there is none\n(i.e. if \"everything is local\"). So that seems intentional. (The\nstructure of REPO1 and your fetch refspecs lines should explain why we\ndon't want anything.)\n\nAbout the \"From\": If fetch displays no note (i.e. \"foo   ref -> ref\") it\ndisplays no \"From\" either, which makes sense. We're not getting anything\nfrom anywhere, we're not even listing up to date info, so we're not\ndisplaying the reference point.\n\nMichael\n"},{"id":"114925","messageId":"32A886B1C4F2374E82704D6CE76D2491020B12C1@exchange-ca2.CA.KRONOS.COM","threadId":"19547","inReplyTo":"4A1E43B1.20400@drmicha.warpmail.net","subject":"RE: exit status = 1 from git fetch -t","fromName":"Villeneuve, Daniel","fromEmail":"daniel.villeneuve@kronos.com","sentAt":"2009-05-28T14:56:54Z","receivedAt":"2009-05-28T14:56:54Z","isPatch":false,"sender":{"key":"daniel.villeneuve@kronos.com","avatar":null},"body":">From: Michael J Gruber [mailto:git@drmicha.warpmail.net] \n>Villeneuve venit, vidit, dixit 28.05.2009 05:57:\n>> I'm getting an unexpected exit status of 1 from \"git fetch\n>> -t\" on one of our largest repositories (by large, I mean 47\n>> branches and 5442 tags, some of which might not be reachable\n>> from branch heads).\n>... \n>> I've compiled git in debug to step in the code, and the\n>> source of the \"error\" exit status seems to come from\n>> builtin-fetch-pack.c:everything_local, where *refs being\n>> NULL leaves retval to 1 in the final loop.\n>> \n>> I'm also puzzled that I don't get the \"From ssh://...\" in\n>> the trace from \"REPO1\" as for the \"REPO2\" repository above.\n>> I do get the \"From ssh://...\"  line if doing only \"git fetch\n>> -v -v\" without the \"-t\" option in \"REPO1\".\n>\n>Looking at that loop, I reckon everything_local() returns 0 if there is\n>at least one object we \"want\" from the remote and 1 if there is none\n>(i.e. if \"everything is local\"). So that seems intentional. (The\n>structure of REPO1 and your fetch refspecs lines should explain why we\n>don't want anything.)\n>\n>About the \"From\": If fetch displays no note (i.e. \"foo   ref -> ref\")\nit\n>displays no \"From\" either, which makes sense. We're not getting\nanything\n>from anywhere, we're not even listing up to date info, so we're not\n>displaying the reference point.\n\nI've cloned both repositories locally, so now everything runs\nwith git 1.6.3.1.  The config is set by clone (called with no\noptions) with just new tracking branches added via \"git branch --track\".\n\nBoth repositories are set in the same way.\n\nDigging further, I've located the divergence point between REPO1 and\nREPO2\nin the return from quickfetch, called from builtin-fetch:fetch_refs.  On\nthe small repository (REPO2, 303 tags), quickfetch succeeds and returns\n0.\nOn the large repository (REPO1, 5439 tags (maybe I lost 3 in the debug\nsetup steps)), quickfetch fails and returns 127.   After that point,\nREPO1 goes on with transport_fetch_refs which causes a non-zero return,\nwhile REPO2 continues with ret==0 and returns 0.\n\nUsing GIT_TRACE=1, we can see that the rev-list command built by\nquickfetch\nfor REPO1 takes about 233930 bytes, which when tried directly from bash\nyields\n\"Argument list too long\".\n\nIn gdb, I also faked a return value of 1 from quickfetch for REPO2, and\nit then\nfollowed the same path as for REPO1, returning an exit status of 1.\n\nSo it seems that the exit status currently depends on which strategy\nis used to identify some missing commits, and it's not clear that\na non-zero exit status indicates an error.\n\nMaybe I should just grep stderr from \"git fetch\" for \".*failed.*\"\ninstead of using the exit status (unless I'm missing something).\n--\nDaniel\n"}]}