Re: git-repack made my pack 317x larger...
- From
- linux@horizon.com <linux@horizon.com>
- Date
- Jun 15, 2007, 14:54 UTC
- Message-ID
- <20070615145433.22970.qmail@science.horizon.com>
- In-Reply-To
- <alpine.LFD.0.99.0706150935530.5651@xanadu.home>
>> 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?)