Re: [PATCH] describe: count the distance correctly when commit dates are skewed

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 4, 2026, 18:29 UTC
Message-ID: <CAHk-=wj-5hp+FZBAqryzTwJ8DKvuNHub2e0kUG3g_+7borFfEQ@mail.gmail.com>
In-Reply-To: <xmqqv76c1mwb.fsf@gitster.g>

On Wed, 4 Nov 2026 at 10:18, Junio C Hamano <gitster@pobox.com> wrote:

>
> Unbelievably bad clock skew.  I wonder if these people do not check
> their machine clock at all, but knowing the answer to that or learning
> why they don't would not help the issue at hand at all, so I'll stop.

For the kernel, people figured out what the issue is: it's not clock skew, it's intentional bad behavior by the gitlab Marge-bot merge logic. Quoting Sasha Levin who root-caused it:

  The media dates seem to come from tooling too: The media CI merges MRs
  with Marge-bot, a GitLab merge bot, which rebases each one onto next
  using --keep-committers [1]. That copies the original committer date
  onto every rebased commit, so an MR landing after a newer one ends up
  older than its new parent.

  [1] https://gitlab.com/marge-org/marge-bot/-/commit/3fb8ab74b8781505530c21a28ac08080bc7deedb

I have told people that I won't be pulling this kind of garbage in the future, but I don't know what insane workflows gitlab has forced on people.

That flag is evil. It's intentionally lying about commit times. And it's what caused "clock skew" of up to three days in the kernel tree.

People should not use gitlab and this disgusting flag.

Don't ask me what complete insanity caused somebody to think that keeping the committer name and email should mean that you should also lie about the commit *date*.

What a complete shit-show.

            Linus