Re: [PATCH v4 35/52] docs: fs: fscrypt.rst: get rid of :c:type: tags

[Mauro Carvalho Chehab]

Em Mon, 5 Oct 2020 12:08:23 -0700
Eric Biggers <ebiggers@xxxxxxxxxx> escreveu:

> On Mon, Oct 05, 2020 at 02:06:22PM +0200, Mauro Carvalho Chehab wrote:
> > The latest version at:
> > 
> > 	https://git.linuxtv.org/mchehab/experimental.git/log/?h=sphinx3-fixes-v4  
> 
> Doesn't work either.
> 
> $ git remote add mchehab https://git.linuxtv.org/mchehab/experimental.git
> $ git fetch mchehab
> warning: alternate disabled by http.followRedirects: https://git.linuxtv.org/git/linux.git/
> warning: alternate disabled by http.followRedirects: https://git.linuxtv.org/git/media_tree.git/
> warning: alternate disabled by http.followRedirects: https://git.linuxtv.org/git/linux.git/
> error: Unable to find 4d9f4b7b8bf7af2d8deb4435833a7e165b9bdd21 under https://git.linuxtv.org/mchehab/experimental.git
> Fetching objects: 286, done.
> Cannot obtain needed object 4d9f4b7b8bf7af2d8deb4435833a7e165b9bdd21
> while processing commit 0a0cde580853340e1a585a1959eaaf055b7cff9a.
> error: fetch failed.

Well, support for https was broken at linuxtv.org. Not many media
developers use https instead of git.

The main issue is that we heavily use alternates there, in order
to minimize disk space usage. After some server upgrade, https
stopped working properly.

I just fixed it, by adding some new rewrite rules that will call
git http-backend in order to solve alternates.

Thanks for reporting it.

> > In the specific case of fscript.rst, there are only two patches on my
> > series affecting it, both as part of this /52 series:  
> 
> But those two patches don't apply because they also change other files.
> 
> I need to apply patches to do a proper review.  Reviewers shouldn't have to
> waste time trying to figure out how to apply your patches.

Yeah, agreed. Sorry for that. 

Not sure what would be the best way to minimize the issues, though.

I mean, I might place those documentation patches on my linux-next
branch, making them visible at tomorrow's linux-next, but that
doesn't sound a good idea, as this will be a source of conflicts,
since several patches from my tree are based on patches applied
via someone's else's tree.

Hopefully, after getting this series merged upstream, the
docs build for html will finally went into a clean state. Any new
warnings that might sleep though maintainer's reviews could
easily be fixed without depending on a 100+ patch series.

-

Btw, there was no new linux-next tag yesterday. The last one is
still next-20201002.

I'll wait for a while a today's linux-next. After rebasing on the
top of that, I'll submit a v5 of this series.

Thanks,
Mauro