On Mon, May 4, 2015 at 2:32 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 04.05.2015 um 17:05 schrieb Robert Dailey: >> >> On Fri, May 1, 2015 at 12:57 PM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote: >>> >>> Hi, >>> >>> On Wed, Apr 29, 2015 at 03:53:11PM -0500, Robert Dailey wrote: >>>> >>>> I am attempting to diff a submodule modified in my working copy and >>>> the only difference is a merge commit. However, I do not get the >>>> "full" range of commits introduced by the merge commit when I diff it: >>>> >>>> $ git diff --submodule=log Core >>>> Submodule Core 8b4ec60..def2f3b: >>>> > Merge remote-tracking branch 'origin/master-ah3k' >>>> >>>> However if I go inside my submodule and run `git log` by hand, I get >>>> more information about the TRUE commits introduced: >>>> >>>> $ git log --oneline 8b4ec60..def2f3b >>>> def2f3b Merge remote-tracking branch 'origin/master-ah3k' >>>> 015c961 Remove log spam in FontManager >>>> 7713ba1 Update third party submodule to latest >>>> 10aac78 Merge pull request #9 in FE/core from >>>> feature/FE-1348-selecting-continue-on-zero-balance to master-ah3k >>>> 287882f FE-1376 Nedd to remain in check detail screen when selecting >>>> donation after SBI >>>> a5a6bed Do not overwrite the current check# within loop >>>> dfb8547 Adding list of checks to CRspChecks before saving >>>> 1be280a FE-1354: Guest logged out in specific multiple check scenario >>>> de06d5a [FE-1348] Fix PATT exit while checks still open >>>> >>>> It's almost as if the `git diff --submodule=log` approach is passing >>>> in --first-parent to git log, which would exclude commits in the range >>>> that I'm seeing when I run git log manually. >>> >>> >>> That is exactly the case. In prepare_submodule_summary() that option is >>> set before doing the revision walk. >>> >>>> Is this by design? Is there a way to enable the full log history with >>>> `git diff` on a submodule? >>> >>> >>> This stems from the first implementation for showing submodule diffs in >>> commit 752c0c24. I guess this was done deliberately to limit the amount >>> of output you get for a submodule. At the moment this is hardcoded but I >>> think there is nothing wrong with adding another option to include the >>> full log. >>> >>> Cheers Heiko >> >> >> I will go ahead and work on this feature. Here is what I'd like to see: >> >> 1. `git diff --submodule` should have the ability to display full logs >> vs current logs (i.e. without --first-parent) > > > I agree. Just recently I started missing that feature too at $DAYJOB. > >> 2. `git submodule summary` should have an option to display full logs >> or "first-parent" logs. > > > No objection against that. Maybe now is a good time to make `git > submodule summary` use `git diff --submodule` internally to make > them behave the same? > >> For #1, do you recommend adding a 3rd setting for `diff.submodule` >> config? Something like "full-log" or something? Or an entirely new >> config? > > > I'd go with a 3rd setting for diff.submodule (and "full-log" would > have been my first choice too ;-). > >> I noticed that in diff.h, the DIFF_OPT flags already consume >> >> 31 bits. If this is a 32-bit flag, there is only 1 bit left. If we go >> with a 3rd setting for `diff.submodule` I think this might consume the >> last bit. > > > Yup. But I'm not sure we can do anything about it. > >> We could also make `git diff --submodule` default to the "full log" >> type, and if users want only first parent logs in submodule summary, >> they'd have to execute `git submodule summary` instead. > > > Please do not change defaults that people lived fine with for years > lightly. But I won't object changing that on a major version if a > majority of users request that. Since I am not a linux user, I have implemented this feature against the Git for Windows fork of git. I am not able to verify changes if I make them directly against the Git repository. Is it OK if you guys end up getting this as an upstream patch later from that project? Also I am not familiar with the bash unit tests, I will need help with that. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html