Re: [PATCH 1/2] fetch-pack: use commit-graph when computing cutoff

From: Taylor Blau <me@ttaylorr.com>
Date: Jan 31, 2022, 22:53 UTC
Message-ID: <YfhoWk1LFnzbFaQf@nand.local>
In-Reply-To: <31cf8f87a149c0fc8013b869e0e30364f3c60e01.1643364888.git.ps@pks.im>

(+cc Stolee, in case anything I'm saying here is wrong)

On Fri, Jan 28, 2022 at 11:17:03AM +0100, Patrick Steinhardt wrote:

Show 6 quoted lines

> One thing to keep in mind though is that the commit-graph corrects
> committer dates:
>
>     * A commit with at least one parent has corrected committer date
>       equal to the maximum of its commiter date and one more than the
>       largest corrected committer date among its parents.

This snippet refers to how correct committer dates are computed, not how the commit dates themselves are stored.

Indeed, the corrected committer date is used to compute the corrected commit date offset, which is the "v2" generation number scheme (as opposed to topological levels, which make up "v1").

But that is entirely separate from the committer dates stored by the commit-graph file, which are faithful representations of the exact committer date attached to each commit.

Looking at the very last few lines of the main loop in write_graph_chunk_data() (where the committer dates are stored):

    if (sizeof((*list)->date) > 4)
      packedDate[0] = htonl(((*list)->date >> 32) & 0x3);
    else
      packedDate[0] = 0;

    packedDate[0] |= htonl(*topo_level_slab_at(ctx->topo_levels, *list) << 2);
    packedDate[1] = htonl((*list)->date);
    hashwrite(f, packedDate, 8);

the low-order 34 bits are used to store the commit's `->date` field, and the remaining high-order 30 bits are used to store the generation number. (You can look in `fill_commit_graph_info()` to see that we only use those 34 bits to write back the date field).

So I think this paragraph (and the ones related to it) about this being an approximation and that being OK since this is a heuristic can all go away.

Thanks, Taylor