Can't understand the behaviour of git-diff --submodule

Can't understand the behaviour of git-diff --submodule

[Francis Moreau]

Hi,

I'm trying to use the --submodule switch with git-diff but doesnt
understand the following behaviour:

$ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
diff --git a/configs b/configs
index 16c6a89..ce12289 160000
--- a/configs
+++ b/configs
@@ -1 +1 @@
-Subproject commit 16c6a89f245f0eed7fb0bce8e027c59fcf1d543e
+Subproject commit ce12289c5bfca7b2c423d9f1871c13ad1ba1dc32

but adding the --submodule option gives:

$ git diff --submodule=log 2c9a257718d1803de720f95766ff256d33accad5 HEAD
Submodule configs 16c6a89...ce12289 (commits not present)

Could anybody enlight me ?
-- 
Francis

Re: Can't understand the behaviour of git-diff --submodule

[Jens Lehmann]

Am 26.10.2012 16:07, schrieb Francis Moreau:
> I'm trying to use the --submodule switch with git-diff but doesnt
> understand the following behaviour:
> 
> $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
> diff --git a/configs b/configs
> index 16c6a89..ce12289 160000
> --- a/configs
> +++ b/configs
> @@ -1 +1 @@
> -Subproject commit 16c6a89f245f0eed7fb0bce8e027c59fcf1d543e
> +Subproject commit ce12289c5bfca7b2c423d9f1871c13ad1ba1dc32
> 
> but adding the --submodule option gives:
> 
> $ git diff --submodule=log 2c9a257718d1803de720f95766ff256d33accad5 HEAD
> Submodule configs 16c6a89...ce12289 (commits not present)
> 
> Could anybody enlight me ?

The output "Submodule configs 16c6a89...ce12289 (commits not present)"
contains same SHA-1s, only in their abbreviated form. That is the same
information you get without the --submodule option, but in shorter
format: it says the submodule moved from 16c6a89 to ce12289 in the
given commit range of the superproject (and the "..." part tells us it
wasn't a fast-forward). The "(commits not present)" part indicates that
even though git diff would have wanted to show you what happened in the
submodule between 16c6a89 and ce12289 by displaying the first line of
each commit message, it couldn't because these commit(s) are not present
in the submodule repo. If you do a "git log --oneline 16c6a89...ce12289"
inside the submodule you'll get an "unknown revision" error for the same
reason.

The "(commits not present)" part should go away and the output of the
short commit messages should appear when you do a "git fetch" inside the
submodule (at least unless someone forgot to push these submodule commits
upstream). As "git fetch" does attempt to fetch all referenced submodules
too, I suspect that you have unpushed commits (e.g. they might have been
dropped because of a rebase). In this case a "git submodule update" will
fail for the same reason.

Does that make it clearer?

Re: Can't understand the behaviour of git-diff --submodule

[Francis Moreau]

Hi,

Thanks for answering

On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 26.10.2012 16:07, schrieb Francis Moreau:
>> I'm trying to use the --submodule switch with git-diff but doesnt
>> understand the following behaviour:
>>
>> $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>> diff --git a/configs b/configs
>> index 16c6a89..ce12289 160000
>> --- a/configs
>> +++ b/configs
>> @@ -1 +1 @@
>> -Subproject commit 16c6a89f245f0eed7fb0bce8e027c59fcf1d543e
>> +Subproject commit ce12289c5bfca7b2c423d9f1871c13ad1ba1dc32
>>
>> but adding the --submodule option gives:
>>
>> $ git diff --submodule=log 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>> Submodule configs 16c6a89...ce12289 (commits not present)
>>
>> Could anybody enlight me ?
>
> The output "Submodule configs 16c6a89...ce12289 (commits not present)"
> contains same SHA-1s, only in their abbreviated form. That is the same
> information you get without the --submodule option, but in shorter
> format: it says the submodule moved from 16c6a89 to ce12289 in the
> given commit range of the superproject (and the "..." part tells us it
> wasn't a fast-forward). The "(commits not present)" part indicates that
> even though git diff would have wanted to show you what happened in the
> submodule between 16c6a89 and ce12289 by displaying the first line of
> each commit message, it couldn't because these commit(s) are not present
> in the submodule repo. If you do a "git log --oneline 16c6a89...ce12289"
> inside the submodule you'll get an "unknown revision" error for the same
> reason.

Well, no the commits are present in the submodule, that's what I tried
to show with the first 'git-diff' command I did in my previous post
(without the --submodule switch).

And to check again, this is the result of git log:

  $ cd configs
  $ git log --oneline 16c6a89...ce12289
  ce12289 test 2

[...]

> Does that make it clearer?

Unforunately not really.

Thanks.
-- 
Francis

Re: Can't understand the behaviour of git-diff --submodule

[Jens Lehmann]

Am 26.10.2012 21:54, schrieb Francis Moreau:
> On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 26.10.2012 16:07, schrieb Francis Moreau:
>>> I'm trying to use the --submodule switch with git-diff but doesnt
>>> understand the following behaviour:
>>>
>>> $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>>> diff --git a/configs b/configs
>>> index 16c6a89..ce12289 160000
>>> --- a/configs
>>> +++ b/configs
>>> @@ -1 +1 @@
>>> -Subproject commit 16c6a89f245f0eed7fb0bce8e027c59fcf1d543e
>>> +Subproject commit ce12289c5bfca7b2c423d9f1871c13ad1ba1dc32
>>>
>>> but adding the --submodule option gives:
>>>
>>> $ git diff --submodule=log 2c9a257718d1803de720f95766ff256d33accad5 HEAD
>>> Submodule configs 16c6a89...ce12289 (commits not present)
>>>
>>> Could anybody enlight me ?
>>
>> The output "Submodule configs 16c6a89...ce12289 (commits not present)"
>> contains same SHA-1s, only in their abbreviated form. That is the same
>> information you get without the --submodule option, but in shorter
>> format: it says the submodule moved from 16c6a89 to ce12289 in the
>> given commit range of the superproject (and the "..." part tells us it
>> wasn't a fast-forward). The "(commits not present)" part indicates that
>> even though git diff would have wanted to show you what happened in the
>> submodule between 16c6a89 and ce12289 by displaying the first line of
>> each commit message, it couldn't because these commit(s) are not present
>> in the submodule repo. If you do a "git log --oneline 16c6a89...ce12289"
>> inside the submodule you'll get an "unknown revision" error for the same
>> reason.
> 
> Well, no the commits are present in the submodule, that's what I tried
> to show with the first 'git-diff' command I did in my previous post
> (without the --submodule switch).

Oh, that only shows the commits of the submodule recorded in the
superproject and not that they are present there (you'll even get
that output when the submodule was never initialized and is empty).

> And to check again, this is the result of git log:
> 
>   $ cd configs
>   $ git log --oneline 16c6a89...ce12289
>   ce12289 test 2
> 
> [...]

That is weird, "git diff --submodule" should show that too. Is there
anything unusual about your setup? (The only explanation I can come
up with after checking the code is that your submodule has neither a
.git directory nor a gitfile or the objects directory in there doesn't
contain these commits)

Re: Can't understand the behaviour of git-diff --submodule

[Francis Moreau]

On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
[...]
>
> That is weird, "git diff --submodule" should show that too. Is there
> anything unusual about your setup? (The only explanation I can come
> up with after checking the code is that your submodule has neither a
> .git directory nor a gitfile or the objects directory in there doesn't
> contain these commits)

Oh now you're asking, I think the submodule has been added by using
the --reference option of git-submodule-add.

  $ cd configs
  $ cat .git
  gitdir: ../.git/modules/configs

Thanks
-- 
Francis

Re: Can't understand the behaviour of git-diff --submodule

[Jens Lehmann]

Am 26.10.2012 22:43, schrieb Francis Moreau:
> On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> [...]
>>
>> That is weird, "git diff --submodule" should show that too. Is there
>> anything unusual about your setup? (The only explanation I can come
>> up with after checking the code is that your submodule has neither a
>> .git directory nor a gitfile or the objects directory in there doesn't
>> contain these commits)
> 
> Oh now you're asking, I think the submodule has been added by using
> the --reference option of git-submodule-add.
> 
>   $ cd configs
>   $ cat .git
>   gitdir: ../.git/modules/configs

Thanks, I suspect the --reference option makes the difference here,
I'll check that as soon as I find some time.

Re: Can't understand the behaviour of git-diff --submodule

[Francis Moreau]

On Sun, Oct 28, 2012 at 1:02 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 26.10.2012 22:43, schrieb Francis Moreau:
>> On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> [...]
>>>
>>> That is weird, "git diff --submodule" should show that too. Is there
>>> anything unusual about your setup? (The only explanation I can come
>>> up with after checking the code is that your submodule has neither a
>>> .git directory nor a gitfile or the objects directory in there doesn't
>>> contain these commits)
>>
>> Oh now you're asking, I think the submodule has been added by using
>> the --reference option of git-submodule-add.
>>
>>   $ cd configs
>>   $ cat .git
>>   gitdir: ../.git/modules/configs
>
> Thanks, I suspect the --reference option makes the difference here,
> I'll check that as soon as I find some time.

Yes that's fairly easy to reproduce:

$ mkdir super
$ cd super
$ git init
$ git submodule add --reference ~/tmp/git-submodule/public/a.git
~/tmp/git-submodule/public/a.git a
$ git commit -m "Initial creation of super project"
$ cd a
$ date >a.txt
$ git commit -a -m "add to a.txt a random change"
$ cd ..
$ git submodule summary
* a 2f8803a...a1aa4bf (1):
  > add to a.txt a random change
$ git commit -a -m "Include a's changes in super project"
$ git diff --submodule=log HEAD~1 HEAD
Submodule a 2f8803a...a1aa4bf (commits not present)

Thanks
-- 
Francis

Re: Can't understand the behaviour of git-diff --submodule

[Jens Lehmann]

Am 28.10.2012 01:02, schrieb Jens Lehmann:
> Am 26.10.2012 22:43, schrieb Francis Moreau:
>> On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> [...]
>>>
>>> That is weird, "git diff --submodule" should show that too. Is there
>>> anything unusual about your setup? (The only explanation I can come
>>> up with after checking the code is that your submodule has neither a
>>> .git directory nor a gitfile or the objects directory in there doesn't
>>> contain these commits)
>>
>> Oh now you're asking, I think the submodule has been added by using
>> the --reference option of git-submodule-add.
>>
>>   $ cd configs
>>   $ cat .git
>>   gitdir: ../.git/modules/configs
> 
> Thanks, I suspect the --reference option makes the difference here,
> I'll check that as soon as I find some time.

Since 1.7.11 and 1.7.10.3 git does handle submodules with alternates
(which is what --reference uses) correctly. What version are you
seeing this problem with?

Re: Can't understand the behaviour of git-diff --submodule

[Francis Moreau]

Hi,

On Tue, Oct 30, 2012 at 10:17 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 28.10.2012 01:02, schrieb Jens Lehmann:
>> Am 26.10.2012 22:43, schrieb Francis Moreau:
>>> On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>> [...]
>>>>
>>>> That is weird, "git diff --submodule" should show that too. Is there
>>>> anything unusual about your setup? (The only explanation I can come
>>>> up with after checking the code is that your submodule has neither a
>>>> .git directory nor a gitfile or the objects directory in there doesn't
>>>> contain these commits)
>>>
>>> Oh now you're asking, I think the submodule has been added by using
>>> the --reference option of git-submodule-add.
>>>
>>>   $ cd configs
>>>   $ cat .git
>>>   gitdir: ../.git/modules/configs
>>
>> Thanks, I suspect the --reference option makes the difference here,
>> I'll check that as soon as I find some time.
>
> Since 1.7.11 and 1.7.10.3 git does handle submodules with alternates
> (which is what --reference uses) correctly. What version are you
> seeing this problem with?

git version 1.7.10.4

Thanks.
-- 
Francis