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

From: Philip Oakley <philipoakley@iee.org>
Date: May 22, 2015, 17:40 UTC
Message-ID: <64326DCF30A041379141BB51437E87A6@PhilipOakley>
In-Reply-To: <xmqq8ucghf2s.fsf@gitster.dls.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>

Show 28 quoted lines

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

Show 12 quoted lines

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