# git log -p file.c

4 messages from 2007-06-14 to 2007-06-14. Participants: Uwe Kleine-Koenig, sf, Jakub Narebski, Linus Torvalds.
Thread: https://gitlist.dev/t/8597

## Uwe Kleine-Koenig, 2007-06-14 09:02

Subject: git log -p file.c
Message-ID: <20070614090217.GA8271@informatik.uni-freiburg.de>
URL: https://gitlist.dev/e/20070614090217.GA8271%40informatik.uni-freiburg.de

```
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

```

## sf, 2007-06-14 10:15

Subject: Re: git log -p file.c
Message-ID: <46711555.5060106@b-i-t.de>
URL: https://gitlist.dev/e/46711555.5060106%40b-i-t.de
In-Reply-To: <20070614090217.GA8271@informatik.uni-freiburg.de>

```
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

```

## Jakub Narebski, 2007-06-14 21:55

Subject: Re: git log -p file.c
Message-ID: <f4shn6$r6q$1@sea.gmane.org>
URL: https://gitlist.dev/e/f4shn6%24r6q%241%40sea.gmane.org
In-Reply-To: <20070614090217.GA8271@informatik.uni-freiburg.de>

```
[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

```

## Linus Torvalds, 2007-06-14 23:16

Subject: Re: git log -p file.c
Message-ID: <alpine.LFD.0.98.0706141611090.14121@woody.linux-foundation.org>
URL: https://gitlist.dev/e/alpine.LFD.0.98.0706141611090.14121%40woody.linux-foundation.org
In-Reply-To: <f4shn6$r6q$1@sea.gmane.org>

```

[ 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

```