Re: [PATCH] pack-objects: protect against disappearing packs

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

 



On Thu, Oct 13, 2011 at 10:42:28PM -0400, Nicolas Pitre wrote:

> > ---
> 
> you should put your SOB above that line I would think.

Thanks. I cheated and wrote my "---" cover letter in the commit message
locally, knowing that it would get included by format-patch but stripped
by am on Junio's end.  Which does work, except that "format-patch -s"
puts the SOB in the wrong place. :)

> Acked-by: Nicolas Pitre <nico@xxxxxxxxxxx>

Thanks for reviewing.

> > We're seeing this at GitHub because we prune pretty
> > aggressively. We let pushes go into individual repositories,
> > but then we kick off a job to move the resulting objects
> > into the repository's "network" repo, which is basically a
> > big alternates repository for related repos.
> 
> While this patch certainly has value, it doesn't provide 100% 
> reliability for that use case.  Maybe the github infrastructure should 
> simply skip any auto-repack on push if some other object maintenance 
> operation is ongoing, possibly via the pre-auto-gc hook.

I'm not sure I understand the problem.  We already serialize the
re-packing jobs in a queue, so you won't have two repacks going at once.
The problematic pack-objects is the one started by upload-pack when
somebody fetches. Or do you mean turning off receive.autogc? I'd have to
check if we do that, but we definitely should; it's useless to us
(though it would be unlikely to trigger anyway, because we are manually
repacking so frequently).

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