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

Nicolas Pitre [off-list ref] 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.