Hello, pabs. IMHO, the notion of a PR/MR is more specific to Git repository management tools (e.g., GitHub, GitLab). They all have specific concepts/ways to manage the way how their hosted repositories behave --- and I believe this flexibility is one of the beauties in Git . I could see how this could be implemented by tools like this rather easily (e.g., using symlinks + inotify or something less hacky). I'm wondering if standardizing this would be more interesting to those communities? I would like to see what becomes of this. Cheers! -Santiago. On Tue, Feb 07, 2017 at 08:32:17AM +0800, Paul Wise 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. > > 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. > > Contributions from people who don't use or dislike MUAs are possible. > > Disadvantages: > > Pull request spam, could be mitigated with configuration options. > > Extra configuration and complexity on the server side. This is once > only and means less complexity on the pull requester side. > > Will not work with typical setups where the git/http/ssh user does not > have write access to the repositories. A workaround could be some sort > of hybrid-repository setup with the new refs and objects in a second > repository which would be shared by all pull requesters. > > -- > bye, > pabs > > http://bonedaddy.net/pabs3/