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

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

[Roberto Tyley]

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

Roberto

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

[Johannes Schindelin]

Hi Roberto,

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.

Thanks so much!
Dscho

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

[Sebastian Schuberth]

On 5/22/2015 10:33, Roberto Tyley wrote:

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

That's fantastic! Me being the one who brought up that topic at the Git 
Merge contributor's summit, I can say this sounds *very* much like the 
tool I've envisioned. Many thanks for that, I'll be sure to give it a 
try as soon as I can.

Best regards,
Sebastian

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

[Stefan Näwe]

Am 22.05.2015 um 10:33 schrieb Roberto Tyley:
> [...]
> 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/

That looks really promising!
I wonder if that wouldn't make a good addition to github's repository ui
in general ?

Thanks,
  Stefan
-- 
----------------------------------------------------------------
/dev/random says: Diplomacy: The patriotic art of lying for one's country.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')" 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[Junio C Hamano]

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.

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

[Johannes Schindelin]

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

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

[Matthieu Moy]

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/

This is absolutely awsome. A few thoughts after testing the system to
send two patches:

* This is awesome :-). Really.

* I found no way to specify a version like [PATCH v2 ...]. Similarly,
  there could be a way to say [RFC/PATCH ...].

* I'm used to 'git send-email' and I have an alias to add the --signoff
  for me. I just sent a series where I forgot the signed-off-by. The
  system could warn if I didn't signoff.

* I had a text+subject for the pull-request, I was expecting a cover
  letter email with them.

* A simple way to add "below-triple-dash" comments would be cool. For
  now, I guess we can do this by having the --- within the commit
  message.

* The explanation on how to register one's email were unclear to me. It
  told me that I had to register my email without telling how, and that
  I had to send the series to myself before. Once I sent the series to
  myself I got better explanation, hence reversing the order of the
  advices would already be an improvement.

* The link to the original PR could be more visible. For now, I can get
  to the PR by clicking the octocat icon, but perhaps a text "click here
  to view the PR on GitHub" or a link on the whole title would have been
  easier to find.

* I missed a way to specify In-reply-to: to follow up to my previous
  version.

* The submitGit link on the top left does nothing for me. I would expect
  to come back to the home page of submitGit.

* For completess: Junio just noticed in another thread that the patch
  order is reversed, PATCH 2/2 predates PATCH 1/2 and the second is
  In-Reply-To: the first.

* I was about to suggest that you post a comment on the GitHub pull
  request when sending the email, but it is already the case, with a
  link to Gmane. Very very cool.

* Did I mention how awesome the application is already? 'Cause it really
  is!

Thanks a lot for doing this!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Junio C Hamano]

Roberto Tyley <roberto.tyley@gmail.com> writes:

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

Hmm, this seems to request too much authorization, though.

    Repositories
    Public only
    This application will be able to read and write all public repo
    data. This includes the following:

    Code
    Issues
    Pull requests
    Wikis
    Settings
    Webhooks and services
    Deploy keys

I really wanted to try this out, but I do not think, as the owner of
a reasonably important repository, it would be irresponsible for me
to grant write access to Code or Settings for my primary GitHub
account.  Also I think you reject an account that is too young (I
found out about submitGit via your comment on a pull request to
git/git and read its source before reading your message I am
responding to, and that was the impression I got from the recent log
messages there), so I cannot create and try with a throw-away
account, either.

That would mean that I cannot join the fun X-<.

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

[Stefan Beller]

On Fri, May 22, 2015 at 1:33 AM, Roberto Tyley <roberto.tyley@gmail.com> 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:

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

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

[Philip Oakley]

From: "Johannes Schindelin" <johannes.schindelin@gmx.de>
> 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


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

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

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
> 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.

I still think this is valuable for the spotting of the dumb mistakes we 
all make, and notice after the fact when we see the email in the hard 
light of day. There will still be poor commit messages and the like, but 
at least the raw content is more likely to be as the author desired.

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

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

[Stefan Beller]

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?

Thanks,
Stefan

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

[Johannes Schindelin]

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

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

[Johannes Schindelin]

Hi Stefan,

On 2015-05-22 21:23, Stefan Beller wrote:
> 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?

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.

Ciao,
Dscho

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

[Junio C Hamano]

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?

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

[Stefan Beller]

On Fri, May 22, 2015 at 1:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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?

I was also asked for read/write on my copy of git, but as I am not
the maintainer nor trusted in any way, I figured that's ok.
I still have my local copy which would notice any changes on git push.

The question I was asking was the only thing I could not answer
or decide for myself.

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

[Philip Oakley]

From: "Johannes Schindelin" <johannes.schindelin@gmx.de>
> 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
>
Do I read you right.. That it's necessary to create a PR on git/git 
before submitGit can be used.

And that if I already have a PR which goes back to an alternate fork 
(e.g. my example), then I must move or duplicate that PR onto git/git 
before it can be used.

[I find a few UI issues with the github interface in that I'd hoped to 
be able to see which outgoing PRs I have from my own fork but I can't 
see how to do that]

regards

Philip 

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

[Johannes Schindelin]

Hi Philip,

On 2015-05-22 23:35, Philip Oakley wrote:

> Do I read you right.. That it's necessary to create a PR on git/git
> before submitGit can be used.

Yep.

> And that if I already have a PR which goes back to an alternate fork
> (e.g. my example), then I must move or duplicate that PR onto git/git
> before it can be used.

Yep, the rationale being that you most likely have to rebase your PR to git/git's `master` branch, anyway.

Ciao,
Dscho

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

[Johannes Schindelin]

Hi Roberto,

On 2015-05-22 23:28, Roberto Tyley wrote:

> I'm currently on a cycling holiday on an island off the west coast of
> Scotland, **without a laptop**, so updates to submitGit (based on the
> excellent feedback I've been receiving) will probably start mid-next week.

Ah, I am jealous. Enjoy your trip!

Ciao,
Dscho

P.S.: The only exposure I had to Scala was for desktop application programming, so I guess I won't try my hand at patching submitGit without your hand-holding. Not urgent, of course.

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

[Johannes Schindelin]

Hi Junio,

On 2015-05-22 22:04, Junio C Hamano wrote:
> 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?

Well, I did not try to send to the mailing list yet. Maybe that's the difference? Or maybe it is because I just registered with Heroku before...

Ciao,
Dscho

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

[Matthieu Moy]

Stefan Beller <sbeller@google.com> writes:

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

I was confused at the same point, but at the top of the screen showing
this message, there was a link to do this registration. I was just not
looking at the right place.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/