Re: Diffing submodule does not yield complete logs for merge commits
- From
- Robert 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?