Re: Diffing submodule does not yield complete logs for merge commits
- From
Stefan Beller <sbeller@google.com>
- Date
- May 19, 2015, 20:34 UTC
- Message-ID
- <CAGZ79kZf_C=QkfQ+LV9G9fLsfqE9USrwkMiNdLmz0-BtPuAmRw@mail.gmail.com>
- In-Reply-To
- <CAHd499D9vOtLOBj2s5EOfsojSStZY+HdZR35icZ5cssLNkcD-A@mail.gmail.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)
Show 7 quoted lines
> > 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 :(
Show 11 quoted lines
> > 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