Re: idea: light-weight pull requests

From: Eric Wong <e@80x24.org>
Date: Feb 7, 2017, 03:11 UTC
Message-ID: <20170207031127.GA29468@dcvr>
In-Reply-To: <1486427537.16949.42.camel@bonedaddy.net>

Paul Wise <pabs3@bonedaddy.net> wrote:

Show 10 quoted lines

> Hi all,
> 
> I had an idea that might be interesting to git folks:
> 
> light-weight pull requests:
> 
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they created when previously identified, without
> forking off a new repository.

I considered something similar to this a few years ago, but decided it wasn't worth the effort (see below).

Show 22 quoted lines

> Advantages:
> 
> Removes the need to look up who to send the pull request notification
> to since configuring that is up to the project itself.
> 
> Removes the annoying scenario of having lots of remotes that have been
> removed after the corresponding pull request was closed.
> 
> Moves popular git hosting services from primarily a model of forests of
> forks to one of contributions to well maintained ongoing projects.
> 
> Allows users to use their preferred git clients to issue pull requests
> instead of using web interfaces of popular git hosting services.
> 
> Creates a new standard for contributing to repositories on all git
> repository hosting services.
> 
> Contributions from people without an account on those services are
> possible.
> 
> Contributions from people without any git repository hosting of their
> own are possible.

All of these are great goals which I'd love to see realized, but...

> Contributions from people who don't use or dislike MUAs are possible.

How would discussion and review happen? People seem to use either mail, or centralized messaging (and the latter often involves non-Free systems like GitHub or Slack).

> Disadvantages:
> 
> Pull request spam, could be mitigated with configuration options.

This is a big one. Maybe CRM114 or another generic/trainable option can be made usable; but I think there'll always be cases where hardcoded rules need to be written (for SpamAssassin, at least) and real-time blacklists need to be checked.

At some point, you might end up having to recreate everything we have in place to combat email spam. Or, use blockchain or something similarly expensive for reputation, which isn't good for poor folks with slow computers.

Anyways, I ultimately decided it would be better to continue supporting and improving email (which is at least entrenched in a few communities, like this one), rather than trying to get people to adopt something new.