>From: Michael J Gruber [mailto:git@xxxxxxxxxxxxxxxxxxxx] >Villeneuve venit, vidit, dixit 28.05.2009 05:57: >> I'm getting an unexpected exit status of 1 from "git fetch >> -t" on one of our largest repositories (by large, I mean 47 >> branches and 5442 tags, some of which might not be reachable >> from branch heads). >... >> I've compiled git in debug to step in the code, and the >> source of the "error" exit status seems to come from >> builtin-fetch-pack.c:everything_local, where *refs being >> NULL leaves retval to 1 in the final loop. >> >> I'm also puzzled that I don't get the "From ssh://..." in >> the trace from "REPO1" as for the "REPO2" repository above. >> I do get the "From ssh://..." line if doing only "git fetch >> -v -v" without the "-t" option in "REPO1". > >Looking at that loop, I reckon everything_local() returns 0 if there is >at least one object we "want" from the remote and 1 if there is none >(i.e. if "everything is local"). So that seems intentional. (The >structure of REPO1 and your fetch refspecs lines should explain why we >don't want anything.) > >About the "From": If fetch displays no note (i.e. "foo ref -> ref") it >displays no "From" either, which makes sense. We're not getting anything >from anywhere, we're not even listing up to date info, so we're not >displaying the reference point. I've cloned both repositories locally, so now everything runs with git 1.6.3.1. The config is set by clone (called with no options) with just new tracking branches added via "git branch --track". Both repositories are set in the same way. Digging further, I've located the divergence point between REPO1 and REPO2 in the return from quickfetch, called from builtin-fetch:fetch_refs. On the small repository (REPO2, 303 tags), quickfetch succeeds and returns 0. On the large repository (REPO1, 5439 tags (maybe I lost 3 in the debug setup steps)), quickfetch fails and returns 127. After that point, REPO1 goes on with transport_fetch_refs which causes a non-zero return, while REPO2 continues with ret==0 and returns 0. Using GIT_TRACE=1, we can see that the rev-list command built by quickfetch for REPO1 takes about 233930 bytes, which when tried directly from bash yields "Argument list too long". In gdb, I also faked a return value of 1 from quickfetch for REPO2, and it then followed the same path as for REPO1, returning an exit status of 1. So it seems that the exit status currently depends on which strategy is used to identify some missing commits, and it's not clear that a non-zero exit status indicates an error. Maybe I should just grep stderr from "git fetch" for ".*failed.*" instead of using the exit status (unless I'm missing something). -- Daniel -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html