Nicolas Pitre <nico@cam.org> writes:

quoted text
> 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.

quoted text
> 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.

quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html