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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 04.05.2015 um 17:05 schrieb Robert Dailey:
> On Fri, May 1, 2015 at 12:57 PM, Heiko Voigt <hvoigt@hvoigt.net> 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.