git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
RDRobert Dailey <rcdailey.lists@gmail.com>
Date
May 30, 2015, 02:18 UTC
Message-ID
<55691DE3.70200@gmail.com>
In-Reply-To
<20150521125122.GA22553@book.hvoigt.net>
On 5/21/2015 7:51 AM, Heiko Voigt wrote:
Show 84 quoted lines
> 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?
Previous: Heiko VoigtNext: Heiko Voigt
Message 16 of 24 in “Diffing submodule does not yield complete logs for merge commits”
  1. Robert DaileyApr 29, 2015
  2. Heiko VoigtMay 1, 2015
  3. Robert DaileyMay 4, 2015
  4. Jens LehmannMay 4, 2015
  5. Robert DaileyMay 4, 2015
  6. Heiko VoigtMay 4, 2015
  7. Johannes SchindelinMay 5, 2015
  8. Robert DaileyMay 15, 2015
  9. Heiko VoigtMay 18, 2015
  10. Robert DaileyMay 18, 2015
  11. Heiko VoigtMay 19, 2015
  12. Robert DaileyMay 19, 2015
  13. Stefan BellerMay 19, 2015
  14. Roberto TyleyMay 22, 2015
  15. Heiko VoigtMay 21, 2015
  16. Robert DaileyMay 30, 2015
  17. Heiko VoigtMay 30, 2015
  18. Junio C HamanoMay 30, 2015
  19. Robert DaileyMay 30, 2015
  20. Robert DaileyMay 30, 2015
  21. Junio C HamanoMay 30, 2015
  22. Robert DaileyMay 30, 2015
  23. Heiko VoigtJun 2, 2015
  24. Junio C HamanoMay 4, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.