All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Gustavo Padovan <gus@collabora.com>
Cc: linux-media@vger.kernel.org,
	"kernelci@lists.linux.dev" <kernelci@lists.linux.dev>,
	Denys Fedoryshchenko <denys.f@collabora.com>
Subject: Re: linux-media checkout failing for KernelCI
Date: Fri, 17 May 2024 19:56:27 +0100	[thread overview]
Message-ID: <20240517195627.28887c2b@sal.lan> (raw)
In-Reply-To: <dba299b0-df43-00f2-f5ec-2078eb8a63e8@collabora.com>

Em Fri, 17 May 2024 09:45:53 -0400
Gustavo Padovan <gus@collabora.com> escreveu:

> ...linuxtv-ci mailing-list rejected me for not being a member, so moving 
> to the media list.
> 
> On 5/17/24 09:41, Gustavo Padovan wrote:
> >
> > Hi Media maintainers,
> >
> > We are struggling to use the media tree, in the same way we usually 
> > virtually all other trees in KernelCI. The following commands gives 
> > KernelCI a fatal error.
> >
> > git clone 
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > cd linux
> > git remote add media https://git.linuxtv.org/media_tree.git
> > git remote update media
> > git fetch --tags https://git.linuxtv.org/media_tree.git
> > fatal: Couldn't find remote ref HEAD

First of all, the best is to use, instead, media_stage.git, as this
contains the most recent patches. You should notice, however, that
we might need to rebase media_stage.git. That doesn't happen often,
but if you use it for CI, just in case, be sure that it will do a

	git reset --hard FETCH_HEAD

To avoid potential problems if a rebase is needed.

We periodically update media_tree.git as well (which never rebases),
but the update is manual. I usually do it once per week between
-rc1 to -rc7, by the time I handle myself pull requests.

For CI, the best is to use media_stage.git.

-

With regards to merge/fetch, please use the git protocol
whenever possible, e. g.:

	git://linuxtv.org/media_tree.git
	git://linuxtv.org/media_stage.git

you may, alternatively use:

	https://linuxtv.org/git/media_tree.git
	https://linuxtv.org/git/media_stage.git

The 4 above url's are handled by git daemon.

If you use, instead:

	https://git.linuxtv.org/media_tree.git

It will use cgit, which will try to do the right thing, but
results may not be consistent, as the main goal for cgit is to
provide a web visual interface (which is IMO a *lot* better than
what git??b provides).

The problem with https is that it may require a hook during
push time to update https references:

	git update-server-info

Currently, we have such hook enabled for media_tree.git and
media_stage.git. I'm not sure if this is still required for
cgit and git-daemon, though.

If one could test it, that would be nice.

We may migrate some day from git-daemon/cgit to something more modern,
like gitlab, but I'd like to keep a patch-based view like the one
provided by cgit, as IMO showing the Kernel tree by default doesn't
really help for our needs: showing the basis of the Kernel tree as
the initial view means nothing, as one can't tell if new patches were
added or not just looking into it.

> > We are in the process of enabling a lot of testing for media using 
> > fluster/gst and the ChromeOS Tast PlatformDecoder tests. I am not a 
> > git behavior expert, so we want to start this thread to discuss 
> > possible solutions as the media tree is for some reason deviating from 
> > some tacit standard.
> >
> > Thoughts?
> >
> > Best,
> >
> > - Gus
> >  
> 

  reply	other threads:[~2024-05-17 18:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 13:41 linux-media checkout failing for KernelCI Gustavo Padovan
2024-05-17 13:45 ` Gustavo Padovan
2024-05-17 18:56   ` Mauro Carvalho Chehab [this message]
2024-05-17 19:46     ` Mauro Carvalho Chehab
2024-05-17 15:29 ` Guenter Roeck
2024-05-17 16:57   ` Gustavo Padovan
2024-05-17 21:40     ` Denys Fedoryshchenko

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=20240517195627.28887c2b@sal.lan \
    --to=mchehab@kernel.org \
    --cc=denys.f@collabora.com \
    --cc=gus@collabora.com \
    --cc=kernelci@lists.linux.dev \
    --cc=linux-media@vger.kernel.org \
    /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.