On Fri, May 22, 2015 at 1:33 AM, Roberto Tyley <roberto.tyley@xxxxxxxxx> wrote: > On Tuesday, 19 May 2015, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey >> <rcdailey.lists@xxxxxxxxx> wrote: >> > How do you send your patches inline? > [snip] >> This workflow discussion was a topic at the GitMerge2015 conference, >> and there are essentially 2 groups, those who know how to send email >> and those who complain about it. A solution was agreed on by nearly all >> of the contributors. It would be awesome to have a git-to-email proxy, >> such that you could do a git push <proxy> master:refs/for/mailinglist >> and this proxy would convert the push into sending patch series to the >> mailing list. It could even convert the following discussion back into >> comments (on Github?) but as a first step we'd want to try out a one >> way proxy. >> >> Unfortunately nobody stepped up to actually do the work, yet :( > > > Hello, I'm stepping up to do that work :) Or at least, I'm implementing a > one-way GitHub PR -> Mailing list tool, called submitGit: Cool! I will try that with the next patch I want to submit. > > https://submitgit.herokuapp.com/ > > Here's what a user does: > > * create a PR on https://github.com/git/git When looking at https://github.com/git/git Git Source Code Mirror - This is a publish-only repository and all pull requests are ignored. Please follow Documentation/SubmittingPatches procedure for any of your improvements. Once this tool has proven to be usable (in a few days?), we want to reword that. Guidelines for submitting patches to Git. Half this document covers how to send a patch via email without it getting corrupted - which submitGit will do for you - but the other half is very useful, giving guidance on what good patches for the Git project should look like. If it turns out this tool is widely used we may want to consider splitting up SubmittingPatches inside git.git into two files, one dealing with the contents i.e. How to write good, reviewable commits, following the coding guide lines and having a proper sign off, and another document on how to get your contributions upstream (email, pull request, ...) > * logs into https://submitgit.herokuapp.com/ with GitHub auth > * selects their PR on https://submitgit.herokuapp.com/git/git/pulls > * gets submitGit to email the PR as patches to themselves, in order to > check it looks ok > * when they're ready, get submitGit to send it to the mailing list on > their behalf > > All discussion of the patch *stays* on the mailing list - I'm not > attempting to change > anything about the Git community process, other than make it easier > for a wider group > people to submit patches to the list. > > For hard-core contributors to Git, I'd imagine that git format-patch & > send-email > remain the fastest way to do their work. But those tools are _unfamiliar to the > majority of Git users_ - so submitGit aims to cater to those users, because they > definitely have valuable contributions to make, which would be tragic > to throw away. > > I've been working on submitGit in my spare time for the past few > weeks, and there > are still features I plan to add (like guiding the user to more > 'correct' word wrapping, > sign-off, etc), but given this discussion, I wanted to chime in and > let people know > what's here so far. It would be great if people could take the time to > explore the tool > (you don't have to raise a git/git PR in order to try sending one *to > yourself*, for > instance) and give feedback on list, or in GitHub issues: > > https://github.com/rtyley/submitgit/issues > > I've been lucky enough to discuss the ideas around submitGit with a > few people at > the Git-Merge conf, so thanks to Peff, Thomas Ferris Nicolaisen, and Emma Jane > Hogbin Westby for listening to me (not to imply their endorsement of > what I've done, > just thanks for talking about it!). Wow! Thanks for doing this, Stefan > > Roberto -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html