Jeff King wrote
> Fundamentally the problem is
> that the --local transport is not safe from propagating corruption, and
> should not be used if that's a requirement.
I've read Jeff Mitchell's blog post, his update, relevant parts of the
git-clone(1) man page, and a decent chunk of this thread, and I'm still not
clear on one thing. Is the danger of `git clone --mirror` propagating
corruption only true when using the --local option ?
Specifically, in my case, I'm using `git clone --mirror`, but I'm *not*
using --local, nor am I using --no-hardlinks. The host executing the clone
command is different than the the host on which the remote repository lives,
and I am using ssh as a transport protocol. If there is corruption, can I
or can I not expect the clone operation to fail and return a non-zero exit
value? If I can not expect this, is the workaround to run `git fsck` on the
View this message in context:
Sent from the git mailing list archive at Nabble.com.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html