From: Taylor Blau <firstname.lastname@example.org> To: "Jakub Narębski" <email@example.com> Cc: Junio C Hamano <firstname.lastname@example.org>, email@example.com, Abhishek Kumar <firstname.lastname@example.org>, Derrick Stolee <email@example.com>, Taylor Blau <firstname.lastname@example.org> Subject: Re: What's cooking in git.git (Sep 2020, #03; Wed, 9) Date: Tue, 15 Sep 2020 15:32:01 -0400 [thread overview] Message-ID: <20200915193201.GA1741@nand.local> (raw) In-Reply-To: <85ft7ivp1t.fsf@LAPTOP-ACER-ASPIRE-F5.i-did-not-set--mail-host-address--so-tickle-me> Hi Jakub, On Tue, Sep 15, 2020 at 09:05:18PM +0200, Jakub Narębski wrote: > I'd like to point out that latest series of patches by Abhishek Kumar > which are final part of 'Implement Generation Number v2' is at what I > believe is next to final iteration: > > "[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date" > https://email@example.com/T/#u > > It is waiting for the decision on *how to implement storing* new > generation number in the commit-graph file: should we store corrected > commit date directly as 64 bit value, or should we store corrected > commit date offset as 32 bit value with overflow handling? > > Switching from 64 bits to 32 bits halves the size of the GDAT > (Generation DATa) chunk, but decreases the size of the commit-graph file > by at most 7%. For large repository, like MS Windows with 3M commits in > 2019 it would mean decreasing the size of the commit-graph file by > 11.8 MiB (if I calculated it correctly). > > Because corrected commit date offsets are not monotone, that is after > value that doesn't fit in 32 bits (in parent) there can be one that does > (in child). It is extremely unlikely that in real repositories there > would be that large corrections needed, but it can happen in theory, and > therfore we need some way to handle overflow if we choose this option. > And of course we should test that overflow handling works correctly. > > So there is tradeoff between complexity and commit-graph file size. If you think that not being able to fit into 32 bits is unlikely, then I don't think it makes sense to store those same values inside of 64 bits, either. Of course, that means implementing overflow detection, but that's a small price to pay for shaving off extra data from the commit-graph file. > Best, > -- > Jakub Narębski Thanks, Taylor
next prev parent reply other threads:[~2020-09-15 19:32 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-09 22:32 Junio C Hamano 2020-09-09 23:07 ` Eric Sunshine 2020-09-10 4:52 ` Junio C Hamano 2020-09-15 22:48 ` Eric Sunshine 2020-09-15 22:54 ` Junio C Hamano 2020-09-15 19:05 ` Jakub Narębski 2020-09-15 19:32 ` Taylor Blau [this message] 2020-09-15 21:14 ` Junio C Hamano 2020-09-15 21:25 ` Jakub Narębski 2020-09-15 21:45 ` Junio C Hamano 2020-09-15 21:48 ` Taylor Blau 2020-09-15 22:32 ` Junio C Hamano 2020-09-15 22:02 ` Jakub Narębski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200915193201.GA1741@nand.local \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: What'\''s cooking in git.git (Sep 2020, #03; Wed, 9)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).