Nicolas Pitre <nico@xxxxxxx> 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. - 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
