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
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
[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
[ Nit-picking. Not really important. But I reacted to a part of Jakub's
explanation ]
On Thu, 14 Jun 2007, Jakub Narebski wrote:
quoted
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