>> 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. Of course, reading the description of git-rev-list --objects, you might get the impression, but it's not exactly hugely obvious. 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". 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. (I might complan a little less if git-repack would take -adlf rather than insisting on -a -d -l -f. Is that a deliberate choice or has just nobody stepped up to revamp the option parsing?) - 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
