Re: [PATCH 00/23] Preliminary pack v4 support
- From
Nicolas Pitre <nico@fluxnic.net>
- Date
- Aug 27, 2013, 15:59 UTC
- Message-ID
- <alpine.LFD.2.03.1308271153370.14472@syhkavp.arg>
- In-Reply-To
- <xmqqioyrfa5m.fsf@gitster.dls.corp.google.com>
On Tue, 27 Aug 2013, Junio C Hamano wrote:
Show 17 quoted lines
> Nicolas Pitre <nico@fluxnic.net> 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.
Show 9 quoted lines
> > 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