[Toybox] GitHub Apps - Repo Lockdown · GitHub

[Rob Landley]

On 8/17/20 10:55 AM, enh wrote:
> On Sun, Aug 16, 2020 at 8:14 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 8/16/20 2:31 PM, enh via Toybox wrote:
>>> https://github.com/apps/repo-lockdown
>>>
>>> Turns out there is a way to automate telling folks with pull requests to try the
>>> mailing list instead. See link.
>>>
>>> (This came up on the tzdata mailing list. I have no personal experience.)
>>
>> Eh, its not a huge deal. The list is my personal preference, but wget pull
>> request plus ".patch" on the end feeds straight into "git am".
> 
> yeah, i've certainly seen you apply patches sent as pull requests. i
> think the bigger problem is that checking pull requests isn't part of
> your workflow in the same way that checking the list is. i'd almost
> responded on https://github.com/landley/toybox/pull/234 that the
> submitter should try sending their patch to the mailing list instead,
> for example.

I get email, there's "patch links" near the bottom of the email, and the one
ending in .patch is a "git am" format patch I can review and apply like any other.

>> There's a generational divide between old people who grew up on mailing lists
>> and younguns who grew up on web forums. People young enough that "here's a list
>> of 37 websites that went away, you can't archive this and will lose your
>> history" gets responded to with "I was 4 when that happened, who cares what
>> happens in 10 years that's forever, we'll burn that bridge when we come to it,
>> and just because it's happened like clockwork for decades doesn't mean it'll
>> happen AGAIN"...
>>
>> As I said, "wide net". The real history is the git commit log I suppose...
> 
> i think the question is which is a worse experience for those younger
> than we mailing list types --- having a pull request automatically
> closed with a "try the mailing list instead" or having a pull request
> accidentally missed because the person who needs to see it mainly
> concentrates on the mailing list?

I usually don't miss the pull request, because email. (Unless I'm not online at
the time and have to remember to download it later when the mail itself is
already marked as read, that isn't 100%.)

But closing it, I have to navigate to the website which I'm not always logged
into even when I am online. (Why github-generated .patch files don't have the
"closes #xxx" magic signature you were telling me about, I couldn't tell you.
They didn't anticipate this workflow, I guess? "I have assumptions about how
this hammer will be used, and it breaks if you don't do that" = cheap hammer.)

I'm aware capitalism loves "allow me to insert my product or service into your
existing daily work flow so you can't get anything done without it", but I break
everything and assume most things go away again after away, and... it's a web
gui for what I do locally on the command line and then push out batch updates
when I remember.

The main advantage of it for _me_ (other than not having to set up a git server
on dreamhost) is to be able to point other people conveniently at a commit
rather than "here's a hash I hope you know how to use git". (If I'm not online
going through email, I can grab the hash out of the URL and "git show" in a
locally checked out tree so it's longer but not _worse_ than just the hash...)

> i'm happy to be the manual nag bot though. for example:
> https://github.com/landley/toybox/pull/234 :-)

Yay, thanks. What's a 234... Ah, I still have a tab open for that one. :)

Rob