Re: Commit cache to speed up rev-list and merge
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Sep 28, 2012, 02:14 UTC
- Message-ID
- <CACsJy8APNsDrTH+hUxgcB=MY0eECCGktm6P1feEEpz2427OQqg@mail.gmail.com>
- In-Reply-To
- <CAJo=hJtoqYEL5YiKawCt_SsSUqfCeYEQzY8Ntyb91cNfNS1w_Q@mail.gmail.com>
On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce <spearce@spearce.org> wrote:
Show 10 quoted lines
> In Linus' Linux kernel tree there are currently about 323,178 commits. > If we store just the pre-parsed commit time as an int32 field this is > an additional 1.2 MiB of data in the pack-*.idx file, assuming we can > use additional data like pack offset position to correlate commit to > the parsed int. If we stored parent pointers in a similar way you > probably need at least 3.6 MiB of additional disk space on the index. > For example, use 12 bytes for each commit to store enough of the > parsed commit time to sort commits, and up to 2 parent pointers per > commit.... with a reserved magic value for octopus merges to mean the > commit itself has to be parsed to get the graph structure correct.
This is much better than my naive approach (storing sha-1 and timestamps). We could use less space by storing parent pointer of non-merge commits only. Merge commits linux-2.6 is 6% the number of commits. git.git has higher percentage, 21%. I bet many projects do not merge as much and the number of merge commits is less than 5%.
-- Duy