On Fri, 15 Jun 2007, linux@xxxxxxxxxxx wrote: > >> Uh... what happened? It's not a full kernel clone, but it's a lot more > >> objects than I expected. Where did all the extra objects come from? > > > Maybe you want to add -l as well to your git-repack invocation. > > Ah. Thank you. Indeed, this is another example of git documentation > disease. git-repack refers to git-pack-objects, which gives a very > technical explanation of what it does, but nowhere is it mentioned that > list of objects suppled to git-pack-object's stdin includes objects > borrowed from alternates. At some point it is necessary for people like you who are not so intimate with the packing code, and therefore to whom this doesn't look obvious, to raise those issues, and ideally provide patches. > Given that "git-repack -f" is a not uncommon command, could I suggest > that the default is wrong, and there should be a special flag for > "suck in alternates, so this repository is no longer dependent > on any others". Well, I tend to disagree here. I don't think using -f _should_ be that common. It is a really expensive operation and you usualy should have a good reason to use it. > Mentally, git-repack is a "reduce space consumption" command, not an > increase one. Having to remember that this repository uses alternates > and add an extra flag to avoid having a space explosion is distinctly > annoying. Why don't you use git-gc then? Its mental model and actual implementation is really about reducing space, maybe even more than git-repack is, and it does call git-repack with -l. Nicolas - 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
