Re: idea: light-weight pull requests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Paul Wise <pabs3@xxxxxxxxxxxxx> wrote:
> 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).

> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]