From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Wed, 17 Jun 2026 10:39:15 GMT
Subject: How does GitGitGadget generate range-diffs, was Re: [PATCH v2 0/6] Support hashing objects larger than 4GB on Windows
Message-ID: <fcb9e52a-5f71-1fd0-a18e-c48e22e6e28c@gmx.de>
In-Reply-To: <xmqqfr2m4gd1.fsf@gitster.g>

Hi Junio,

On Wed, 17 Jun 2026, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > Range-diff vs v1:
> >
> >  1:  84e1cd0aa0 = 1:  9c01bac407 hash-object: demonstrate a >4GB/LLP64 problem
> >  2:  809d83e46f ! 2:  aa5859c14f object-file.c: use size_t for header lengths
> >      @@ Commit message
> 
> By the way, how is range-diff driven via GGG?  After applying these
> patches on the same base commit, my "git range-diff v1...v2" invocation
> punts on matching step 2 and I do not get a comparison like this unless
> I give --creation-factor=<large number> from the command line.

GitGitGadget is using range-diff to compare between iterations of
essentially the same patches, therefore it encourages `range-diff` to try
harder to look for matches via `--creation-factor=95`:
https://github.com/gitgitgadget/gitgitgadget/blob/bf9140eef184/lib/patch-series.ts#L722

The full details how the magic number "95" was determined is in the commit
https://github.com/gitgitgadget/gitgitgadget/commit/2605f72f92bb0ff63f4db91eaf91969749568dd7
(essentially, I played with a couple of values and known hard-cases of
actual, real-world patch series iterations and 95 was the best
compromise).

Ciao,
Johannes