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

On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
[off-list ref] 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