Re: [PATCH/RFH] send-pack: fix pipeline.

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

 



Linus Torvalds <torvalds@xxxxxxxx> writes:

> On Fri, 29 Dec 2006, Junio C Hamano wrote:
>>
>> I really need a sanity checking on this one.  I think I got the
>> botched pipeline fixed with the patch I am replying to, but I do
>> not understand the waitpid() business.  Care to enlighten me?
>
> I think it was a beginning of a half-hearted attempt to check the exit 
> status of the rev-list in case something went wrong.
>
> Which we simply don't do, so if git-rev-list ends up with some problem 
> (due to a corrupt git repo or something), it will just send a partial 
> pack.
>
> For some reason I thought we had fixed that by just generating the object 
> list internally, but I guess we don't do that. That's just stupid. We 
> should make "send-pack.c" use
>
> 	list-heads | git pack-objects --revs
>
> 	list-heads | git-rev-list --stdin | git-pack-objects
>
> because as it is now, I think send-pack is more fragile than it needs to 
> be.
>
> Or maybe I'm just confused.

Dont' worry, you are no more confused than I am ;-).

"I thought we've done the 'pack-objects --revs' for the
upload-pack side but haven't done so on the send-pack side." was
what I initially wrote, but apparently we haven't.  On the other
hand, I think upload-pack gets error termination from rev-list
right.

It seems that repack is the only thing that uses the internal
rev-list.

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