Re: Subject: [PATCH] git-merge-pack

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 7, 2007, 04:43 UTC
Message-ID: <7vwsv36q6p.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.0.9999.0709061942320.21186@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

> I would have concatenated all packs provided on the command line into a 
> single one, simply by reading data from existing packs and writing it 
> back without any processing at all.  The offset for OBJ_OFS_DELTA is 
> relative so a simple concatenation will just work.

As I was planning to do this outside of pack-objects, I did not want to write something that intimately knows the details of packfile format, but see below.

> All data is read once and written once making it no more costly than a 
> simple file copy.  On the flip side it wouldn't get rid of duplicated 
> objects (I don't know if that matters i.e. if something might break with 
> the same object twice in a pack).

I do not think duplicates create problems, as long as the pack idx remains sane. But a bigger issue is for people who fetch over dumb protocols, from a repository that repacks with "-a -d" every once in a while. There, many duplicates are norm.

> In fact, since we want to _also_ perform a repack of loose objects in 
> the context of automatic repacking, I wonder why we wouldn't use that 
> --unpacked= argument to also repack smallish packs at the same time in 
> only one pack-objects pass.  Or maybe I'm missing something?

I think this is a much better idea. You obviously need some twist to the pack-objects, and being lazy that was the reason I did not want to do this that way.

When a new parameter, perhaps --lossless, is given, together with the --unpacked= parameters, we can change pack-objects to iterate over all objects in the --unpacked= packs, and add the ones that are not marked for inclusion to the set of objects to be packed, after doing the usual "objects to be packed" discovery.

I am not sure --lossless is a good option name from marketing point of view, though.