Re: Bug: git-upload-pack will return successfully even when it can't read all references

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 08, 2015 at 02:16:03PM +0200, Ævar Arnfjörð Bjarmason wrote:

> I wonder if --upload-pack="GIT_REF_PARANOIA=1 git-upload-pack" should
> be the default when running fetch if you have --prune enabled. There's
> a particularly bad edge case now where if you have permission errors
> on the master repository and run --prune on your backup along with a
> --mirror clone to mirror the refs, then when you have permission
> issues you'll prune everything from the backup.
> 
> But yeah, a proper fix needs protocol v2. Because among other things
> that --upload-pack hack will only work for ssh, not http.

Right. There is no real way to flip the flag from the client side,
because we cannot reliably communicate it. Once we have such a
mechanism, it might actually make sense to _always_ flip on paranoia.
That is, we would rather an operation fail and be retried with in a
"loose" mode explicitly. That's safer. It's less convenient when you
have a broken repo, but surely that's the exception, right?

-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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]