{"thread":{"id":"8597","subject":"git log -p file.c","startedAt":"2007-06-14T09:02:17Z","lastAt":"2007-06-14T23:16:09Z","messageCount":4,"participants":["Uwe Kleine-Koenig","sf","Jakub Narebski","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45054","messageId":"20070614090217.GA8271@informatik.uni-freiburg.de","threadId":"8597","inReplyTo":null,"subject":"git log -p file.c","fromName":"Uwe Kleine-Koenig","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-06-14T09:02:17Z","receivedAt":"2007-06-14T09:02:17Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"hello,\n\nwhen I run\n\n\tgit log -p file.c\n\nI don't get the complete change a commit introduces but only how file.c\nchanged.  This is kind of surprising for me, I had expected to get the\nwhole diff.\n\nReading git-log(1), -p should \"Show the change the commit introduces in\na patch form.\"  It's not 100% clear, but as I understand it, this means\nthe whole patch should be shown?\n\nAnd is it intended that (clean) merges are shown?\n\nBest regards\nUwe\n\nPS: I currently have only very limited access to the internet, so the\nversion used is 1.5.2.1.133.gd44c7.  Sorry if that issue is already\nresolved :-)\n\n-- \nUwe Kleine-Koenig\n\nhttp://www.google.com/search?q=gigabyte+in+bit\n"},{"id":"45058","messageId":"46711555.5060106@b-i-t.de","threadId":"8597","inReplyTo":"20070614090217.GA8271@informatik.uni-freiburg.de","subject":"Re: git log -p file.c","fromName":"sf","fromEmail":"sf@b-i-t.de","sentAt":"2007-06-14T10:15:49Z","receivedAt":"2007-06-14T10:15:49Z","isPatch":false,"sender":{"key":"sf@b-i-t.de","avatar":null},"body":"Uwe Kleine-Koenig wrote:\n> hello,\n> \n> when I run\n> \n> \tgit log -p file.c\n> \n> I don't get the complete change a commit introduces but only how file.c\n> changed.  This is kind of surprising for me, I had expected to get the\n> whole diff.\n\ngit log --full-diff -p file.c\n\n(--full-diff seems to be undocumented)\n\nRegards\n\nStephan\n"},{"id":"45097","messageId":"f4shn6$r6q$1@sea.gmane.org","threadId":"8597","inReplyTo":"20070614090217.GA8271@informatik.uni-freiburg.de","subject":"Re: git log -p file.c","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-06-14T21:55:06Z","receivedAt":"2007-06-14T21:55:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nUwe Kleine-Koenig wrote:\n\n> when I run\n> \n>       git log -p file.c\n> \n> I don't get the complete change a commit introduces but only how file.c\n> changed.  This is kind of surprising for me, I had expected to get the\n> whole diff.\n\nTry unfortunately _undocumented_ --full-diff option to git-log.\n\n        git log -p --full-diff -- file.c\n\n(the --full-diff option was introduced in commit-477f2b41 without adding\nappropriate info to Documentation/git-log.txt)\n\n> And is it intended that (clean) merges are shown?\n\nPath limiting simplifies history, and might linearize it (i.e. merges\nbecome non-merges).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"45098","messageId":"alpine.LFD.0.98.0706141611090.14121@woody.linux-foundation.org","threadId":"8597","inReplyTo":"f4shn6$r6q$1@sea.gmane.org","subject":"Re: git log -p file.c","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-14T23:16:09Z","receivedAt":"2007-06-14T23:16:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Nit-picking. Not really important. But I reacted to a part of Jakub's \n  explanation ]\n\nOn Thu, 14 Jun 2007, Jakub Narebski wrote:\n> \n> > And is it intended that (clean) merges are shown?\n> \n> Path limiting simplifies history, and might linearize it (i.e. merges\n> become non-merges).\n\nActually, path limiting, when it simplifies merges, will *only* simplify a \nmerge when one of the parents was identical to the end result (which \nimplies that the other parents were obviously not interesting as far as \nthe end result is concerned!).\n\nBut that has a secondary effect: such a merge will then (by definition) \nalways be simplified away, since the simplified merge no longer makes any \nchanges to the set of files in question!\n\nSo \"merges become non-merges\" is not really true (except in a very \ninternal sense that will be invisible to the outside). They either stay as \nmerges (end result is different from any of the parents on their own), or \nthey go away entirely (end result is identical to one of the parents and \nthe merge ends up not containing any change atr all).\n\nThis explanation may, of course, be more nit-picking than anybody really \nwanted to hear.\n\n\t\t\tLinus\n"}]}