git log -p file.c

git log -p file.c

[Uwe Kleine-Koenig]

hello,

when I run

	git log -p file.c

I don't get the complete change a commit introduces but only how file.c
changed.  This is kind of surprising for me, I had expected to get the
whole diff.

Reading git-log(1), -p should "Show the change the commit introduces in
a patch form."  It's not 100% clear, but as I understand it, this means
the whole patch should be shown?

And is it intended that (clean) merges are shown?

Best regards
Uwe

PS: I currently have only very limited access to the internet, so the
version used is 1.5.2.1.133.gd44c7.  Sorry if that issue is already
resolved :-)

-- 
Uwe Kleine-Koenig

http://www.google.com/search?q=gigabyte+in+bit

Re: git log -p file.c

[sf]

Uwe Kleine-Koenig wrote:
> hello,
> 
> when I run
> 
> 	git log -p file.c
> 
> I don't get the complete change a commit introduces but only how file.c
> changed.  This is kind of surprising for me, I had expected to get the
> whole diff.

git log --full-diff -p file.c

(--full-diff seems to be undocumented)

Regards

Stephan

Re: git log -p file.c

[Jakub Narebski]

[Cc: git@vger.kernel.org]

Uwe Kleine-Koenig wrote:

> when I run
> 
>       git log -p file.c
> 
> I don't get the complete change a commit introduces but only how file.c
> changed.  This is kind of surprising for me, I had expected to get the
> whole diff.

Try unfortunately _undocumented_ --full-diff option to git-log.

        git log -p --full-diff -- file.c

(the --full-diff option was introduced in commit-477f2b41 without adding
appropriate info to Documentation/git-log.txt)

> And is it intended that (clean) merges are shown?

Path limiting simplifies history, and might linearize it (i.e. merges
become non-merges).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git log -p file.c

[Linus Torvalds]

[ Nit-picking. Not really important. But I reacted to a part of Jakub's 
  explanation ]

On Thu, 14 Jun 2007, Jakub Narebski wrote:
> 
> > And is it intended that (clean) merges are shown?
> 
> Path limiting simplifies history, and might linearize it (i.e. merges
> become non-merges).

Actually, path limiting, when it simplifies merges, will *only* simplify a 
merge when one of the parents was identical to the end result (which 
implies that the other parents were obviously not interesting as far as 
the end result is concerned!).

But that has a secondary effect: such a merge will then (by definition) 
always be simplified away, since the simplified merge no longer makes any 
changes to the set of files in question!

So "merges become non-merges" is not really true (except in a very 
internal sense that will be invisible to the outside). They either stay as 
merges (end result is different from any of the parents on their own), or 
they go away entirely (end result is identical to one of the parents and 
the merge ends up not containing any change atr all).

This explanation may, of course, be more nit-picking than anybody really 
wanted to hear.

			Linus