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

2015-05-23 Thread 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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-23 Thread 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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-23 Thread 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.schinde...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-23 Thread Matthieu Moy
Stefan Beller sbel...@google.com writes:

 Ok, I am trying it out now, all I have left is

 Register your email address
 (stefanbel...@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/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Roberto Tyley
On Tuesday, 19 May 2015, Stefan Beller sbel...@google.com wrote:
 On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
 rcdailey.li...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Johannes Schindelin
Hi,

On 2015-05-22 19:14, Philip Oakley wrote:
 From: Johannes Schindelin johannes.schinde...@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 sbel...@google.com wrote:
 On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
 rcdailey.li...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Stefan Beller
On Fri, May 22, 2015 at 1:04 PM, Junio C Hamano gits...@pobox.com wrote:
 On Fri, May 22, 2015 at 12:59 PM, Johannes Schindelin
 johannes.schinde...@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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread 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
 (stefanbel...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Philip Oakley

From: Johannes Schindelin johannes.schinde...@gmx.de

Hi,

On 2015-05-22 19:14, Philip Oakley wrote:

From: Johannes Schindelin johannes.schinde...@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 sbel...@google.com wrote:

On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
rcdailey.li...@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 


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Johannes Schindelin
Hi Roberto,

On 2015-05-22 10:33, Roberto Tyley wrote:
 On Tuesday, 19 May 2015, Stefan Beller sbel...@google.com wrote:
 On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
 rcdailey.li...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread 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

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread 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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread 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 sbel...@google.com wrote:
 On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
 rcdailey.li...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Junio C Hamano
Roberto Tyley roberto.ty...@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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Stefan Beller
On Fri, May 22, 2015 at 1:33 AM, Roberto Tyley roberto.ty...@gmail.com wrote:
 On Tuesday, 19 May 2015, Stefan Beller sbel...@google.com wrote:
 On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
 rcdailey.li...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Matthieu Moy
Roberto Tyley roberto.ty...@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/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Junio C Hamano
Roberto Tyley roberto.ty...@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-.



--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Stefan Beller
Ok, I am trying it out now, all I have left is

Register your email address
(stefanbel...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Philip Oakley

From: Johannes Schindelin johannes.schinde...@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 sbel...@google.com wrote:

On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
rcdailey.li...@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 


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2015-05-22 Thread Philip Oakley

From: Junio C Hamano gits...@pobox.com

Roberto Tyley roberto.ty...@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 


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html