Re: propagating repo corruption across clone
On Mon, Mar 25, 2013 at 12:32:50PM -0400, Jeff Mitchell wrote:
Show 6 quoted lines
> I think what was conflating the issue in my testing is that with
> --mirror it implies --bare, so there would be checking of the objects
> when the working tree was being created, hence --mirror won't show the
> error a normal clone will -- it's not a transport question, it's just
> a matter of the normal clone doing more and so having more data run
> through checks.
Show 5 quoted lines
> However, there are still problems. For blob corruptions, even in this
> --no-hardlinks, non --mirror case where an error was found, the exit
> code from the clone was 0. I can see this tripping up all sorts of
> automated scripts or repository GUIs that ignore the output and only
> check the error code, which is not an unreasonable thing to do.
Yes, this is a bug. I'll post a series in a minute which fixes it.
> For commit corruptions, the --no-hardlinks, non --mirror case refused
> to create the new repository and exited with an error code of 128. The
> --no-hardlinks, --mirror case spewed errors to the console, yet
> *still* created the new clone *and* returned an error code of zero.
I wasn't able to reproduce this; can you post a succint test case?
> It seems that when there is an "error" as opposed to a "fatal" it
> doesn't affect the status code on a clone; I'd argue that it ought to.
Agreed completely. The current behavior is buggy.
-Peff
Jeff King <peff@peff.net>