All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: Derrick Stolee <stolee@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/2] fetch-pack: use commit-graph when computing cutoff
Date: Wed, 2 Feb 2022 13:46:34 +0100	[thread overview]
Message-ID: <Yfp9KsvvQa5yWuLE@ncase> (raw)
In-Reply-To: <YfhoWk1LFnzbFaQf@nand.local>

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

On Mon, Jan 31, 2022 at 05:53:14PM -0500, Taylor Blau wrote:
> (+cc Stolee, in case anything I'm saying here is wrong)
> 
> On Fri, Jan 28, 2022 at 11:17:03AM +0100, Patrick Steinhardt wrote:
> > 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

Aha, that makes a lot of sense. Thanks a lot for correcting my
misconception! I'll send a v2 of this patch series with the corrected
commit message.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-02-02 12:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28 10:15 [PATCH 0/2] fetch: speed up mirror-fetches with many refs Patrick Steinhardt
2022-01-28 10:17 ` [PATCH 1/2] fetch-pack: use commit-graph when computing cutoff Patrick Steinhardt
2022-01-31 22:53   ` Taylor Blau
2022-02-02 12:46     ` Patrick Steinhardt [this message]
2022-01-28 10:19 ` [PATCH 2/2] fetch: skip computing output width when not printing anything Patrick Steinhardt
2022-02-02 12:51 ` [PATCH v2 0/2] fetch: speed up mirror-fetches with many refs Patrick Steinhardt
2022-02-02 12:51   ` [PATCH v2 1/2] fetch-pack: use commit-graph when computing cutoff Patrick Steinhardt
2022-02-09 18:01     ` Christian Couder
2022-02-10 11:43       ` Patrick Steinhardt
2022-02-02 12:51   ` [PATCH v2 2/2] fetch: skip computing output width when not printing anything Patrick Steinhardt
2022-02-09 18:10     ` Christian Couder
2022-02-10 12:23       ` Patrick Steinhardt
2022-02-10 12:28   ` [PATCH v3 0/2] fetch: speed up mirror-fetches with many refs Patrick Steinhardt
2022-02-10 12:28     ` [PATCH v3 1/2] fetch-pack: use commit-graph when computing cutoff Patrick Steinhardt
2022-02-10 12:28     ` [PATCH v3 2/2] fetch: skip computing output width when not printing anything Patrick Steinhardt
2022-02-10 18:04     ` [PATCH v3 0/2] fetch: speed up mirror-fetches with many refs Junio C Hamano

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yfp9KsvvQa5yWuLE@ncase \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=stolee@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.