Re: Diffing submodule does not yield complete logs for merge commits

[Stefan Beller <sbeller@google.com>]

On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
<rcdailey.lists@gmail.com> wrote:
> How do you send your patches inline?

There are various ways to do so.
If you look at https://github.com/git/git/blob/master/Documentation/SubmittingPatches
and search for Thunderbird (I used to use Thunderbird for a long time
before switching to
git send-email, so I'll take that as an example) at the bottom:

    Thunderbird, KMail, GMail
    -------------------------

    See the MUA-SPECIFIC HINTS section of git-format-patch(1).

Ok, indirection is the fun part of computers. ;)
So you'd look at the man page of git format patch,
such as here http://git-scm.com/docs/git-format-patch
and scroll the way down to MUA-SPECIFIC HINTS, which offers
3 different ways of doing it. (decisions!)

> Do you use git send-email?

I do, but I remember my initial struggle with it (I will contribute only
one patch anyway, so why care?)

> I have
> tried that and it is horrible to setup. Do you just copy/paste the
> patch inline in your compose window?

Once setup correctly git formatpatch / send-email are actually very
convenient (e.g. git send-email HEAD^ --to=git@vger.kernel.org will
just work. And I have strong confidence in it continuing to work,
even when Git decides to revamp the preferred patch format,
line wrapping or other exotic stuff)

>
> It would be much simpler to fork Git, create a branch, make my change,
> and initiate a pull request. I can get email notifications on comments
> to my PR diff and address them with subsequent pushes to my branch
> (which would also automatically update the code review). Turn around
> times for collaborating on a change are much quicker via Github pull
> requests.

Github has indeed an excellent product, even free for open source.

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

>
> I am willing to review the typical workflow for contributing via git
> on mailing lists but I haven't seen any informative reading material
> on this. I just find using command line to email patches and dealing
> with other issues not worth the trouble. Lack of syntax highlighting,
> lack of monospace font, the fact that I'm basically forced to install
> mail client software just to contribute a single git patch.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html