list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <>
To: "Jakub Narębski" <>
Cc: Junio C Hamano <>,, Abhishek Kumar <>,
	Derrick Stolee <>, Taylor Blau <>
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"
> 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,

Of course, that means implementing overflow detection, but that's a
small price to pay for shaving off extra data from the commit-graph

> Best,
> --
> Jakub Narębski


  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:

  List information:

* 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 \ \ \ \ \ \ \
    --subject='Re: What'\''s cooking in git.git (Sep 2020, #03; Wed, 9)' \

* 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:

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).