Re: [PATCH 00/23] Preliminary pack v4 support

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

 



On Tue, 27 Aug 2013, Junio C Hamano wrote:

> Nicolas Pitre <nico@xxxxxxxxxxx> writes:
> 
> > Subject says it all... at last !
> >
> > This can also be fetched here:
> >
> > 	git://git.linaro.org/people/nico/git
> >
> > Demonstration of what it does at the moment:
> >
> > 	http://article.gmane.org/gmane.comp.version-control.git/233038
> >
> > I'd like to preserve the author time stamps as they relate to where in
> > the world I was when the corresponding code was written.  You'll notice
> > I didn't work on the code in the same order as it is now presented.
> 
> We can also notice things like "From: user@machine.(none)" ;-)

Heh.

> > Still open question: what to do with a thin pack.  Should we really
> > complete it with local objects upon reception, or were we only over
> > paranoid at the time we imposed this rule?
> 
> I do not think paranoia had much to do with it.  I am afraid that
> allowing a delta in a pack to depend on a base in another pack means
> that the former pack becomes unusable without the latter, which
> would make object store management (e.g. partial repacking) a lot
> more cumbersome, no?

That's what I'm wondering.  We already end up with a broken repository 
if the commit graph is spread across multiple packs and one of those 
pack is removed.  Having a delta base in a separate pack is not much 
different in that regard.

So the rule could be that any kind of repacking must not carry over 
deltas with a non local base i.e. repack always produces delta 
references belonging to the same pack.


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]