> mid October would be a good time to aim for, what do you think?

Awesome! I am quite busy as well, its the final year of my thesis (finally!). So I like to change my mind here and there by looking on easy-to-fix issues on other projects :D... 

> I saw some PR activity on GH that is highly appreciated. Hope I'll have time to update sr.ht soon. 

I keep SH updated with the PRs that I accept on GH already (curling the patch to `git am` is indeed really straightforward). 
Similarly, I push the changes on SH when I add new features myself and replay the patch on GH to keep it in sync as well. So far so good. It is just a bit annoying to manage the two repos like that.

> Will check out how to give you write access to issues.

Thank you!

Hi Rene,

Do you have an idea of when we will actually complete the migration to SH?

Also, I wanted to add a few labels and stuff on source hut issues tracker, but
it seems that I can not edit anything there. Maybe you need to add me as
maintainer there as well? Could you look into that?

Bests,

- Thomas

> What I like about the patch curling, is: I don't have to add an
> additional (GitHub) remote (which is also the case when pulling in a
> PR directly from one specific PR author's repo) polluting my .git
> directory, and don't have to pollute my repo with a million branches of
> stale PRs either (which I assume is the case - I haven't tried it).

True. Indeed this adds all PRs all the time and pollutes your git quite
a lot for repo with many PRs and stuff. I never had this issue before as
I worked only on some very small scale projects. But I just found a fix
while looking a bit more [1]. This allows to only pull one PR at a time
and is a bit more elegant (and it has a clean alias to remove old PR
branches). You would still need to add the second remote though...

> I think at the moment I still prefer the patch version. However,

Hi Rene,

In your reply on PR 158, you mentioned a workflow for checking locally GitHub
PRs using `curl` and `git am`. I did not want to go off topic on that PR
discussion, so I send this email instead...

> BTW: If you add `.patch` to the PR URL, you get a nicely formatted patch:
>
> https://patch-diff.githubusercontent.com/raw/renerocksai/telekasten.nvim/pull/158.patch
>
> Curling the patch and piping it to `git am` is super easy. relaxed - well,
> usually. Unfortunately, you using tabs and spaces, this somehow makes git
> complain. So I had to re-format the patch to make it apply in order to
> briefly smoke-test it.

> Not an unreasonable request. I sent a patch, let's see what Drew
> says.

Awesome, thank you! The patch is all good for me.

> But personal taste notwithstanding, I'd argue that a note about this
> particular "limitation" of the CSP in the sr.ht pages docs would make
> sense given that I am not the first one to stumble upon this. Will
> gladly provide a patch if Drew deems this necessary.

I agree 100% with that.

While I understand Drew's point and where he comes from, opening external links
in tabs in now an expected behavior for most websites. Personally I am not
willing to compromise on that feature. It's perfectly ok, it just means that
SourceHut sites are not for me. No need to get philosophical here.

That being said, I just lost 2 hours migrating my website from Gitlab to
SourceHut and then trying to understand why my hugo-built website was not

> You need to update your plugin via your plugin manager, so that helptags
> will get re-generated.

Ok. I was not aware of that mechanism. All good for me then.

I just tested the patch. I don't know why, but `:help telekasten.transitioning`
does not work on my end. Nvim can not autocomplete either.

The privacy policy of SourceHut does not mention anything regarding
the data collected about visitors of websites hosted under
<username>.srht.site, nor for visitors of websites with a custom domain
but hosted on sourcehut.

I am not a lawyer, but I think the GDPR impose website administrators
to identify all that stuff properly. I assume that, as for the rest
of the service, only minimal data is collected (IP ?) and for a short
period of time. But this is still something that should be addressed
publicly so it can be easier for website admins to be 100% compliant.

In general, the privacy policy does not really differentiate the
logged-in users with an account and the website visitors. So it is
unclear as well in that aspect (from my understanding, IANAL).

I was a bit annoyed that there is no "watch" function like in Github
to stay informed of the latest developments.

... And then I realized that SourceHut has RSS feeds for the git log!
The link is in the upper right corner of the
[log page](https://git.sr.ht/~renerocksai/telekasten.nvim/log).
You can even watch some specific branches (wiki).

Awesome!