Git Mailing List Archive on
 help / color / 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
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 index

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:

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on

Archives are clonable:
	git clone --mirror git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ \
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone