Re: command return values

[Brian Craft <bcboy@thecraftstudio.com>]

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@peff.net> 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
>