public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH v2] commit-graph: fix writing generations with dates exceeding 34 bits
Date: Wed, 25 Mar 2026 06:36:57 +0100	[thread overview]
Message-ID: <acN0efJvZ9liex8d@pks.im> (raw)
In-Reply-To: <xmqq1ph92pzs.fsf@gitster.g>

On Tue, Mar 24, 2026 at 08:42:31AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Changes in v2:
> >   - Account for platforms where `timestamp_t` has 32 bit precision. This
> >     matches logic in `write_graph_chunk_data()`, where we also depend on
> >     the size of the commit timestamps.
> 
> > +static timestamp_t compute_generation_offset(struct commit *c)
> > +{
> > +	timestamp_t masked_date;
> > +
> > +	if (sizeof(timestamp_t) > 4)
> > +		masked_date = c->date & (((timestamp_t) 1 << 34) - 1);
> > +	else
> > +		masked_date = c->date;
> 
> It is a bit surprising that on a platform where timestamp_t is only
> 32-bit wide, a smart-enough compiler would not find (1<<34) as
> suspicious. 

It probably would, but we don't test on any system where that's the case
to the best of my knowledge. `timestamp_t` is defined as `uintmax_t`,
and that should be 64 bit on almost all platforms. There's going to be
exceptions though, even though I'm not sure whether such platforms even
matter to us. But I later realized that we had similar checks elsewhere,
so I decided to adapt accordingly.

> IOW, I would have expected this to be done not with runtime switch but
> with conditional compilation.

Well, it's written as a runtime switch, but I would expect all compilers
to essentially turn this into conditional compilation. They should note
that the condition is always true (or false) on a given platform. And
checking Godbolt my assumption seems to hold. On x86-64 using GCC [1]:

    compute_generation_offset(unsigned long, unsigned long):
            movabs  rax, 17179869183
            and     rdi, rax
            mov     rax, rsi
            sub     rax, rdi
            ret

Thanks!

Patrick

[1]: https://godbolt.org/z/oa4xPohGb

  reply	other threads:[~2026-03-25  5:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17 19:02 [PATCH] commit-graph: fix writing generations with dates exceeding 34 bits Patrick Steinhardt
2026-03-17 19:39 ` Junio C Hamano
2026-03-19  6:56   ` Patrick Steinhardt
2026-03-20 17:21     ` Derrick Stolee
2026-03-24  6:18 ` [PATCH v2] " Patrick Steinhardt
2026-03-24 15:42   ` Junio C Hamano
2026-03-25  5:36     ` Patrick Steinhardt [this message]
2026-03-26 10:02   ` Karthik Nayak

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=acN0efJvZ9liex8d@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox