Re: [PATCH v2] fetch-pack: optionally save packs to disk

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

 



On Fri, Jun 12, 2015 at 11:07 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> What is the problem with the current fetch-pack implementation? Does
>> it remove a bogus packfile after download? Does it abort during
>> download when it detects a broken packfile? Does --keep not do what
>> you need?
>
> Doesn't the incoming data still go through the fattening process,
> though?  You will not be able to inspect the byte-for-byte identical
> stream that came out of the server end whose packfile generation
> logic is suspect.
>
> For the purpose of debugging your own new server implementation, it
> might be a better approach to capture the pack as it comes out at
> the server end, instead of doing it at the fetch-pack end as it
> comes in. But the approach to add this "dump" at the fetch-pack side
> is that it gives us a tool to diagnose problems that come from
> broken server (re)implementations by other people we cannot debug,
> i.e. "you are spewing this corrupt pack against this request; here
> is a dump we took to help you go fix your server".

*nod* that's an important part of it. Also, in the small-pull case,
the pack data gets sent to unpack-objects anyway, so git is never
saving the packfile anywhere in that case (I think it's for a pull of
less than 100 objects, which characterizes most of my reduced test
cases for weirdness.)

>
>> Instead of your approach (which forks off tee to dump a copy of the
>> packfile), would it not be simpler to add an option --debug-pack
>> (probably not the best name) that skips the cleanup step when a broken
>> packfile is detected and prints the name of the downloaded packfile?
>
> As long as we need to debug a thin pack that comes from the other
> end, that approach is not sufficient, I am afraid.
>
> I anticipated that you'd have problem with its use of "tee".  It
> probably can do this internally with async interface, perhaps,
> instead?

I'd be happy to make such changes if that's the consensus and someone
can give me pointers. My C is admittedly pretty rusty from non-use,
and I'm not at all familiar with git's codebase, but I'll at least
try.

Thanks!
--
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]