Re: [GIT PULL for v7.4] media updates

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Hi Linus,

On Sat, 31 Oct 2026 14:14:37 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 31 Oct 2026 at 00:47, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > And if people are playing games with commit dates, they need to stop
> > doing that. NOW. Because I'm not pulling the media tree until this is
> > dealt with.  
> 
> Note that this is more than "don't lie" (although that's the biggest
> issue to me personally - I don't want to see people lying about what
> is going on).
> 
> It actually broke git this merge window. See
> 
>    https://lore.kernel.org/all/20261031065525.19883-2-torvalds@kernel.org/
> 
> for a patch I sent to the git mailing list to make git-describe show
> the right commit counts.
> 
> Git doesn't depend on commit dates for _correctness_, but they are
> used for a few heuristics for quick history traversal.
> 
> So if you lie about commit times, or are committing on a broken
> machine with dates completely off, the resulting repository data is
> actively worse.

As Sasha mentioned:

On Sat, 31 Oct 2026 22:25:23 -0400
Sasha Levin <sashal@kernel.org> wrote:

> GitLab shows the same pattern for all the commits you found: the copy each
> committer pushed sits on an older parent with the same committer date, and the
> rebased branch that landed was pushed by marge-bot. For your example, Sakari
> pushed the alvium fix on top of
> 
>   b38d06ad1e13 ("media: ipu6: Fix up missing IWYU issue")
> 
> His MR with
> 
>   63c578491cb4 ("media: sun6i-csi: bridge: Use V4L2 subdev active state")
> 
> merged at 22:10 UTC on Sep 16, and at 22:11 marge-bot pushed the alvium
> MR rebased on top of it, still dated Sep 15.
> 
> So in both cases it's the tooling being funny.

Those are caused by the way we merge patches from different sources.
Currently, we use gitlab mainly because we want its actions to run
media CI.

The way it works is that multiple committers can send merge requests
to it, each starting CI pipelines to do several checks, including
compilation with different configs, checkpatch, sparse, smatch
(there is ~10 checks it runs).

Then, either Hans or myself merge the pull request, preserving the
original committer and timestamp. The goal of preserving it is to
preserve who generated the merge request. This is done using a
tool calling margebot.

We opted to do that instead of using merges, as sometimes we're
picking very small merge requests with just one patch or two.
So, if we don't do that:

- a media pull request during the merge window will end with
  dozens of merge requests on it;
- a media fixes PR will have several merge requests
  as each fix will have its own PR.

So, this is due to our attempt to not pollute upstream with
those internal pull requests.

Now, there two ways to avoid that:

1. a one-line change at marge-bot, applying a patch that Ricardo 
   prepared yesterday:

	https://gitlab.com/marge-org/marge-bot/-/merge_requests/676

   This will keep preserving the committer, but will change the timestamp
   for it to be monotonically increased, losing the original timestamp
   representing when the committer merged the patch.

   We use this procedure to allow us to have multiple merge requests
   to run at CI at the same time, as CI usually takes 30m to 1h per
   merge request. By using this procedure, maintainers can apply
   multiple merge requests at the same time, letting CI to
   automatically test each of them, only actually completing the
   merge after it completes successfully without any errors or
   warnings. 

   As test time varis from series to series, it means that merges
   will be done asynchronously, not preserving the MR order.

2. switch to one merge per each committer merge.

   With that, every media merge request will have its own merge at the
   media history, which would reflect on upstream merges.

   So, for instance, merges during release candidates will have those merges 
   inside it:

	https://gitlab.freedesktop.org/linux-media/media-committers/-/merge_requests/?sort=created_date&state=merged&target_branches%5B%5D=fixes&first_page_size=20

   So, for instance this PR:
	https://lore.kernel.org/linux-media/20261028014050.3614d83a@foz.lan/

   with a single fix would have instead two patches(*):

	Sakari Ailus (1):
	      Revert "media: Don't hide I²C or SPI drivers by default"
	Mauro Carvalho Chehab (1):
	      Merge tag 'mr-426' of https://gitlab.freedesktop.org/linux-media/media-committers into next

   which is probably not what you want.

   Also, we would need to ensure at gitlab that each merge will 
   generate its own tag.

   (*) we could minimize it to only do a merge if the parent is
       different, but still when we have more than one media fix PR,
       we'll end with media internal merge requests at the history.

   The ones inside the merge window will also reflect the media
   merge requests:
	https://gitlab.freedesktop.org/linux-media/media-committers/-/merge_requests/?sort=created_date&state=merged&target_branches%5B%5D=next&first_page_size%3D20

   So, you would see dozens of merges on media PRs during the merge
   window.

   the advantage of this approach would be to keep preserving the 
   exact timestamps from the committer.

Based on past discussions with regards to avoiding to send internal
merges to the upstream tree, I think (1) fits better.

Either way, either (1) or (2) should probably avoid the issues you
mentioned with git describe.

Thanks,
Mauro