Re: [PATCH] git-unbundle - unbundle objects and references for disconnected transfer.

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

 



On Wed, 14 Feb 2007, Mark Levedahl wrote:

> Shawn O. Pearce wrote:
> > Mark Levedahl <mdl123@xxxxxxxxxxx> wrote:
> >   
> > > +# get the objects
> > > +unzip -p "$bfile" .gitBundlePack | git-unpack-objects
> > >     
> >
> > Since you are transporting a packfile by sneakernet it might
> > be reasonable to assume this transfer happens infrequently.
> > Consequently we might assume its object count exceeds
> > transfer.unpackLimit, which means a standard fetch or push would
> > have kept the packfile rather than unpacking it to loose objects.
> >
> > So maybe use git-index-pack here to index the packfile and
> > retain it as-is, rather than unpacking it?
> >
> >   
> Many of my uses of this result in 10-20 objects being transferred, so I'm not
> sure keeping each pack is a real benefit. In particular, one use is for daily
> updates between two sites via email where we tend to have a lot of extra
> objects in the packs as we assume that not every bundle actually gets applied,
> while the number of real new objects tends to be small. On the other hand,
> given the manual nature of this operation, we could always just follow up with
> repack -a -d, possibly guarded by a git count. Thoughts?

Since this is meant for manual operation and therefore is not meant to 
happen multiple times per minute, I'd suggest you still use index-pack 
unconditionally instead of unpack-objects despite having a small number 
of objects.


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