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

[Robert Dailey <rcdailey.lists@gmail.com>]

On 5/21/2015 7:51 AM, Heiko Voigt wrote:
> On Tue, May 19, 2015 at 02:29:55PM -0500, Robert Dailey wrote:
>> On Tue, May 19, 2015 at 5:44 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
>>> On Mon, May 18, 2015 at 10:06:32AM -0500, Robert Dailey wrote:
>>>> Unfortunately I find it unintuitive and counter productive to perform
>>>> inline patches or do anything on a mailing list. Especially on
>>>> Windows, it's a pain to setup git to effectively do this. Also I read
>>>> mailing lists through Gmail which does not offer a proper monospace
>>>> font view or syntax coloring to effectively review patches and
>>>> comments pertaining to them.
>>>
>>> Are you sure you are not overestimating the effort it takes to send
>>> patches inline? Once you've got your user agent correctly setup its just
>>> a matter of copy and paste instead of attaching the patch. On Windows I
>>> would probably use Thunderbird which has a section in the format-patch
>>> documentation how to configure it. Compared to the effort you probably
>>> spent on writing your patch isn't this bit of extra effort neglectable?
>>> And your patch is almost done. It just needs some tests and maybe a few
>>> rounds on the mailinglist after that.
>>>
>>>> Since I am not willing to properly follow your process, I will
>>>> withdraw my patch. However it is here if someone else wishes to take
>>>> it over. Really wish you guys used github's amazing features but I
>>>> understand that Linus has already made his decision in that matter.
>>>
>>> It not just Linus decision it is also a matter of many people are used
>>> to this workflow. AFAIR there have been many discussions and tries about
>>> using other tools. Email has many advantages which a webinterface does
>>> not provide. It is simply less effort that one person adjusts to this
>>> workflow instead of changing many peoples working workflow.
>>>
>>>> I'm sorry I couldn't be more agreeable on the matter. Thanks for the
>>>> time you spent reviewing my patch.
>>>
>>> If you are really this fixed in your workflow that would be too bad.
>>
>> How do you send your patches inline? Do you use git send-email? I have
>> tried that and it is horrible to setup. Do you just copy/paste the
>> patch inline in your compose window?
>
> For bigger patch series I did use send-email but currently I am back to
> just using the compose window from whatever email client I am using. On
> Windows that would be Thunderbird. But when possible I am not using
> Windows.
>
>> 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.
>
> I think that depends more on the collaborators than on the tool. When
> you get quick replies the turnaround times with both workflows are
> quick.
>
> It would be nice if there was a perfect solution for every project that
> everyone could use but unfortunately there is not so we sometimes have
> to adjust. But I think its more matter of what you are used to. If you
> did not have a github account but email software setup you could
> complain about the fact that you need to register a github account, fork
> git, setup that fork in your local repository, ... instead of just copy
> and paste your change into the compose window and then send it to a
> mailinglist.
>
>> 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.
>
> As already mentioned by Stefan there is Documentation/SubmittingPatches
> in the Git repository that describes everything and also has a section
> on how to do that with Thunderbird.
>
> I tend to not do much on the commandline on Windows since it basically
> sucks there. For sending patches you just need
>
> 	git format-patch HEAD^
>
> and thats it.
>
> Cheers Heiko
>

So I am working on trying to setup my environment (VM through Virtual 
Box) to do some testing on this. You all have encouraged me to try the 
mailing list review model. So I won't give up yet.

In the meantime I'd like to ask, do we even need to add an option for 
this? What if we just make `diff.submodule log` not use --first-parent? 
This seems like a backward compatible change in of itself. And it's 
simpler to implement. I can't think of a good justification to add more 
settings to an already hugely complex configuration scheme for such a 
minor difference in behavior.

Thoughts?