Re: If you would write git from scratch now, what would you change?

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

 



On Mon, 26 Nov 2007, Dana How wrote:

> On Nov 26, 2007 12:55 PM, Nicolas Pitre <nico@xxxxxxx> wrote:
> > On Mon, 26 Nov 2007, Dana How wrote:
> > > On Nov 26, 2007 11:52 AM, Nicolas Pitre <nico@xxxxxxx> wrote:
> > > > On Mon, 26 Nov 2007, Dana How wrote:
> > > > Then you can do just that for big enough blobs where "big enough" is
> > > > configurable: encapsulate them in a pack instead of a loose object.
> > > > Problem solved.  Sure you'll end up with a bunch of packs containing
> > > > only one blob object, but given that those blobs are so large to be a
> > > > problem in your work flow when written out as loose objects, then they
> > > > certainly must be few enough not to cause an explosion in the number of
> > > > packs.
> > > Are you suggesting that "git add" create a new pack containing
> > > one blob when the blob is big enough?
> > Exactly.
> I will think about your suggestion
> (and the number of packs that might result),
> but I confess I am surprised by it.
> 
> When I proposed automatically extracting large blobs from source
> packs when creating a new pack under a blob size limit while
> pack-objects was running,  you objected on the grounds that
> pack-objects only creates packs and should not create blobs
> (this proposal had other problems too,  but this is the one you didn't like).
> 
> Now it's OK for git-add to sometimes create packs instead of blobs?
> I would not have predicted that!

Going back to loose objects from packs is indeed something I object to 
if it becomes part of a work flow.  Objects should move from the loose 
space towards the packed space and not the other way around.  Sure there 
is fetch.unpackLimit, but with the auto-repack recently added to Git 
this variable could probably be set even lower.

But having a pack created for huge blobs up front has many advantages, 
the most obvious is the fact that later repack can combine and/or send 
those single-blob packs with almost no cost.

Loose objects are meant to be blazingly fast to create.  Once repacked 
they have no advantage being loose again.  Obviously when your blob is 
huge you won't benefit much from a loose object.


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]

  Powered by Linux