Ah, you're right about the return value. I was losing it in a scripting error. And breaking down "clone -b" is a good work-around for the non-existent branch. Thanks! b.c. On Sun, Jul 11, 2010 at 4:37 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Jul 10, 2010 at 09:11:18PM -0700, Brian Craft wrote: > >> I'm finding that "git clone" doesn't return useful error codes, e.g. >> trying to clone from a bad repository. Also, it doesn't abort if you >> try to clone a branch that doesn't exist. The command succeeds, >> leaving you with the wrong result. I haven't found a way to tell when >> the command really succeeds, except for scraping the output. > > It should give useful error codes. I see: > > $ git clone parent child; echo $? > Cloning into child... > done. > 0 > > $ git clone bogus child; echo $? > Cloning into child... > fatal: '/home/peff/foo/bogus' does not appear to be a git repository > fatal: The remote end hung up unexpectedly > 128 > > $ find parent -depth | xargs chmod ogu-r > $ git clone parent child; echo $? > Cloning into child... > fatal: failed to open '/home/peff/foo/parent/.git/objects': Permission > denied > 128 > > So those all seem reasonable. Is there some other case of a "bad > repository" that fails but gets you a zero exit code? > > For the case of a non-existent branch, I see: > > $ git clone -b bogus parent child; echo $? > Cloning into child... > done. > warning: Remote branch bogus not found in upstream origin, using HEAD > instead > 0 > > So yes, it completes with a warning. I agree that is not ideal, as a > script that clones has no idea that it did not actually get the data it > was looking for. > > I think the rationale for not aborting totally is that we have done > significant work (including network traffic) during the clone, and the > warning can generally be remedied with "git checkout the-right-branch". > We could perhaps keep the repository but signal with a non-zero exit > code. > > The other option for a script is not to use "-b", which only impacts > checkout. Instead, you could do: > > $ git clone -n parent child && > cd child && > git checkout -b interesting-branch origin/interesting-branch > > which is just as efficient, but lets you react differently to failure of > each part. You can also break it down further into: > > $ git init && > git remote add origin parent && > git fetch origin && > git branch interesting-branch origin/interesting-branch && > git checkout interesting-branch > > but I don't think there is much point in doing so. > > -Peff > -- 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