[Announce] submitGit for patch submission (was "Diffing submodule does not yield complete logs")

> 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 :(

> On Tuesday, 19 May 2015, Stefan Beller <sbeller@google.com> wrote:
>> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
>> <rcdailey.lists@gmail.com> 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:
> 
> https://submitgit.herokuapp.com/

> On 2015-05-22 10:33, Roberto Tyley wrote:
>> On Tuesday, 19 May 2015, Stefan Beller <sbeller@google.com> wrote:
>>> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
>>> <rcdailey.lists@gmail.com> 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:
>>
>> https://submitgit.herokuapp.com/
> 
> Wow!!!
> 
> I will make sure to test it with a couple of patches I want to submit anyway.

> Hi Roberto,
>
> On 2015-05-22 11:42, Johannes Schindelin wrote:
>
>> On 2015-05-22 10:33, Roberto Tyley wrote:
>>> On Tuesday, 19 May 2015, Stefan Beller <sbeller@google.com> wrote:
>>>> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
>>>> <rcdailey.lists@gmail.com> 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:
>>>
>>> https://submitgit.herokuapp.com/
>>
>> Wow!!!
>>
>> I will make sure to test it with a couple of patches I want to submit 
>> anyway.
>
> I just tried this with https://github.com/git/git/pull/139 and would 
> like to tell you about two wishes I had immediately:
>
> - If the author of a patch I am submitting is not myself, could 
> submitGit maybe add that `From: ` line at the top of the mail?
> - The patch series is sent without a cover letter, but it would be 
> *really* great if a path series consisting of more than one patch 
> could have the initial comment of the Pull Request as a cover letter, 
> with the link to the original Pull Request at the bottom? This would 
> also be the mail to use in the "In-reply-yo" header instead of the 
> first patch.
>
> Thanks so much!
> Dscho

>> On 2015-05-22 11:42, Johannes Schindelin wrote:
>>
>>> On 2015-05-22 10:33, Roberto Tyley wrote:
>>>> On Tuesday, 19 May 2015, Stefan Beller <sbeller@google.com> wrote:
>>>>> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
>>>>> <rcdailey.lists@gmail.com> 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:
>>>>
>>>> https://submitgit.herokuapp.com/
>>>
>>> Wow!!!
>>>
>>> I will make sure to test it with a couple of patches I want to submit anyway.
>>
>> I just tried this with https://github.com/git/git/pull/139 and would like to tell you about two wishes I had immediately:
>>
>> - If the author of a patch I am submitting is not myself, could submitGit maybe add that `From: ` line at the top of the mail?
>> - The patch series is sent without a cover letter, but it would be *really* great if a path series consisting of more than one patch could have the initial comment of the Pull Request as a cover letter, with the link to the original Pull Request at the bottom? This would also be the mail to use in the "In-reply-yo" header instead of the first patch.
>>
>> Thanks so much!
>> Dscho
> 
> 
> A separate request would be to be able to use PRs that are for forks
> of git/git, such as msysgit etc. (i.e. have a common --root), which
> would help in the upstreaming of some changes.
> 
> 
> I ask because I just logged in and my preparatory PR318
> (https://github.com/msysgit/git/pull/318) for rejuvenating the
> msvc-build system wasn't listed, probably because of the forking.

> Hi,
>
> On 2015-05-22 19:14, Philip Oakley wrote:
>> From: "Johannes Schindelin" <johannes.schindelin@gmx.de>
>
>>> On 2015-05-22 11:42, Johannes Schindelin wrote:
>>>
>>>> On 2015-05-22 10:33, Roberto Tyley wrote:
>>>>> On Tuesday, 19 May 2015, Stefan Beller <sbeller@google.com> wrote:
>>>>>> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
>>>>>> <rcdailey.lists@gmail.com> 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:
>>>>>
>>>>> https://submitgit.herokuapp.com/
>>>>
>>>> Wow!!!
>>>>
>>>> I will make sure to test it with a couple of patches I want to 
>>>> submit anyway.
>>>
>>> I just tried this with https://github.com/git/git/pull/139 and would 
>>> like to tell you about two wishes I had immediately:
>>>
>>> - If the author of a patch I am submitting is not myself, could 
>>> submitGit maybe add that `From: ` line at the top of the mail?
>>> - The patch series is sent without a cover letter, but it would be 
>>> *really* great if a path series consisting of more than one patch 
>>> could have the initial comment of the Pull Request as a cover 
>>> letter, with the link to the original Pull Request at the bottom? 
>>> This would also be the mail to use in the "In-reply-yo" header 
>>> instead of the first patch.
>>>
>>> Thanks so much!
>>> Dscho
>>
>>
>> A separate request would be to be able to use PRs that are for forks
>> of git/git, such as msysgit etc. (i.e. have a common --root), which
>> would help in the upstreaming of some changes.
>>
>>
>> I ask because I just logged in and my preparatory PR318
>> (https://github.com/msysgit/git/pull/318) for rejuvenating the
>> msvc-build system wasn't listed, probably because of the forking.
>
> You can easily change what upstream your PR is intended for. For 
> example, I made my PR from my own Git fork (which is based on 
> msysgit/git) relative to git/git by entering the URL:
>
> https://github.com/git/git/compare/next...dscho:non-win-fixes?expand=true
>
> So there is no real need for anything extra: the only git.git project 
> that requires emails (that I am aware of) for the submission process 
> is git/git.
>
> Ciao,
> Dscho
>

> [...]
> 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:
> 
> https://submitgit.herokuapp.com/

> Here's what a user does:
>
> * create a PR on https://github.com/git/git
> * logs into https://submitgit.herokuapp.com/ with GitHub auth
> * selects their PR on https://submitgit.herokuapp.com/git/git/pulls

> Roberto Tyley <roberto.tyley@gmail.com> writes:
>
>> 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:
>>
>> https://submitgit.herokuapp.com/
>
> Yay ;-)
>
>> Here's what a user does:
>>
>> * create a PR on https://github.com/git/git
>> * logs into https://submitgit.herokuapp.com/ with GitHub auth
>> * selects their PR on https://submitgit.herokuapp.com/git/git/pulls
>
> Reasonable.
>
>> * gets submitGit to email the PR as patches to themselves, in order 
>> to
>> check it looks ok
>
> I can see you are trying to be careful by doing this, but I am not
> sure if this step would actually help. Those who are not familiar
> with Git development are not expected to know what is "ok" in their
> original commit, and if they find bad formatting done by submitGit
> (e.g. adds their PR message before the three-dash line instead of
> after it), they cannot do much about it anyway.

>
>> * when they're ready, get submitGit to send it to the mailing list on
>> their behalf
>
> Nice.
>
>> All discussion of the patch *stays* on the mailing list
>
> Can you identify a reroll of an earlier submission?  If you can use
> the in-reply-to and make it a follow-up to the previous round, that
> would be great.
> --

> Ok, I am trying it out now, all I have left is
> 
>     Register your email address
>     (stefanbeller@googlemail.com)
>     with submitGit's Amazon SES
>     account in order for it to send
>     emails from you.
> 
> So first of all:
> Where do I find the Amazon SES account for submitGit, to register
> my email with?
> 
> Also can I change the email in the process or change it before?

>
> On 2015-05-22 21:23, Stefan Beller wrote:
>>
>> So first of all:
>> Where do I find the Amazon SES account for submitGit, to register
>> my email with?
>>
>> Also can I change the email in the process or change it before?
>
> FWIW I did not have to register my email. All I needed to do was to give submitGit
> permissions to read my personal email address and my public repositories.

> On Fri, May 22, 2015 at 12:59 PM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
>>
>> On 2015-05-22 21:23, Stefan Beller wrote:
>>>
>>> So first of all:
>>> Where do I find the Amazon SES account for submitGit, to register
>>> my email with?
>>>
>>> Also can I change the email in the process or change it before?
>>
>> FWIW I did not have to register my email. All I needed to do was to give submitGit
>> permissions to read my personal email address and my public repositories.
>
> Hmph, I was asked way more than that (especially, read and write access).
> Does the site ask different authorizations depending on who you are?

> On Fri, May 22, 2015 at 12:59 PM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
>>
>> On 2015-05-22 21:23, Stefan Beller wrote:
>>>
>>> So first of all:
>>> Where do I find the Amazon SES account for submitGit, to register
>>> my email with?
>>>
>>> Also can I change the email in the process or change it before?
>>
>> FWIW I did not have to register my email. All I needed to do was to give submitGit
>> permissions to read my personal email address and my public repositories.
> 
> Hmph, I was asked way more than that (especially, read and write access).
> Does the site ask different authorizations depending on who you are?

> Ok, I am trying it out now, all I have left is
>
>     Register your email address
>     (stefanbeller@googlemail.com)
>     with submitGit's Amazon SES
>     account in order for it to send
>     emails from you.
>
> So first of all:
> Where do I find the Amazon SES account for submitGit, to register
> my email with?
>
> Also can I change the email in the process or change it before?

> On Tuesday, 19 May 2015, Stefan Beller <sbeller@google.com> wrote:
>> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
>> <rcdailey.lists@gmail.com> 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:

>
> https://submitgit.herokuapp.com/
>
> Here's what a user does:
>
> * create a PR on https://github.com/git/git

> * 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!).