git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Robert Dailey <rcdailey.lists@gmail.com>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: Heiko Voigt <hvoigt@hvoigt.net>, Git <git@vger.kernel.org>
Subject: Re: Diffing submodule does not yield complete logs for merge commits
Date: Mon, 4 May 2015 15:21:31 -0500	[thread overview]
Message-ID: <CAHd499CRge9Y6VzdC_ngXS4WxuQ9HizXQJzLpX3iQStY5Cg=6g@mail.gmail.com> (raw)
In-Reply-To: <5547C961.7070909@web.de>

On Mon, May 4, 2015 at 2:32 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> 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.

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.

  reply	other threads:[~2015-05-04 20:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29 20:53 Diffing submodule does not yield complete logs for merge commits Robert Dailey
2015-05-01 17:57 ` Heiko Voigt
2015-05-04 15:05   ` Robert Dailey
2015-05-04 19:32     ` Jens Lehmann
2015-05-04 20:21       ` Robert Dailey [this message]
2015-05-04 20:51         ` Heiko Voigt
2015-05-05  5:49         ` Johannes Schindelin
2015-05-15 20:33           ` Robert Dailey
2015-05-18 12:30             ` Heiko Voigt
2015-05-18 15:06               ` Robert Dailey
2015-05-19 10:44                 ` Heiko Voigt
2015-05-19 19:29                   ` Robert Dailey
2015-05-19 20:34                     ` Stefan Beller
2015-05-22  9:17                       ` Roberto Tyley
2015-05-21 12:51                     ` Heiko Voigt
2015-05-30  2:18                       ` Robert Dailey
2015-05-30 10:41                         ` Heiko Voigt
2015-05-30 17:04                         ` Junio C Hamano
2015-05-30 19:19                           ` Robert Dailey
2015-05-30 19:37                             ` Robert Dailey
2015-05-30 19:54                             ` Junio C Hamano
2015-05-30 20:25                               ` Robert Dailey
2015-06-02 12:02                                 ` Heiko Voigt
2015-05-04 21:03     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHd499CRge9Y6VzdC_ngXS4WxuQ9HizXQJzLpX3iQStY5Cg=6g@mail.gmail.com' \
    --to=rcdailey.lists@gmail.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).