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

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

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?