Re: propagating repo corruption across clone
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Mar 26, 2013, 01:06 UTC
- Message-ID
- <CACsJy8CZvDfCPPbsRkKJJXiQNpuQOXD-Hm-A7ePbu9tFaG_v5A@mail.gmail.com>
- In-Reply-To
- <20130325155600.GA18216@sigill.intra.peff.net>
On Mon, Mar 25, 2013 at 10:56 PM, Jeff King <peff@peff.net> wrote:
Show 29 quoted lines
> On Mon, Mar 25, 2013 at 10:31:04PM +0700, Nguyen Thai Ngoc Duy wrote: > >> On Mon, Mar 25, 2013 at 9:56 PM, Jeff King <peff@peff.net> wrote: >> > There are basically three levels of transport that can be used on a >> > local machine: >> > >> > 1. Hard-linking (very fast, no redundancy). >> > >> > 2. Byte-for-byte copy (medium speed, makes a separate copy of the >> > data, but does not check the integrity of the original). >> > >> > 3. Regular git transport, creating a pack (slowest, but should include >> > redundancy checks). >> > >> > Using --no-hardlinks turns off (1), but leaves (2) as an option. I >> > think the documentation in "git clone" could use some improvement in >> > that area. >> >> Not only git-clone. How git-fetch and git-push verify the new pack >> should also be documented. I don't think many people outside the >> contributor circle know what is done (and maybe how) when data is >> received from outside. > > I think it's less of a documentation issue there, though, because they > _only_ do (3). There is no option to do anything else, so there is > nothing to warn the user about in terms of tradeoffs. > > I agree that in general git's handling of corruption could be documented > somewhere, but I'm not sure where.
I think either a section in git-fsck.txt or git.txt. Probably the former as people who read it are probably more concerned about corruption.
-- Duy