{"thread":{"id":"39846","subject":"git log fails to show all changes for a file","startedAt":"2015-07-14T07:30:35Z","lastAt":"2015-07-15T19:22:32Z","messageCount":13,"participants":["Olaf Hering","John Keeping","Andreas Schwab","Linus Torvalds","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"266103","messageId":"20150714073035.GA22707@aepfle.de","threadId":"39846","inReplyTo":null,"subject":"git log fails to show all changes for a file","fromName":"Olaf Hering","fromEmail":"olaf@aepfle.de","sentAt":"2015-07-14T07:30:35Z","receivedAt":"2015-07-14T07:30:35Z","isPatch":false,"sender":{"key":"olaf@aepfle.de","avatar":"https://avatars.githubusercontent.com/u/942324?v=4"},"body":"\nI wonder why this command fails to show all commits that modify a given\nfunction: \n\n linux.git $ git log -p -M --stat -- drivers/hv/channel_mgmt.c\n\nWith commit 1f656ff3fdddc2f59649cc84b633b799908f1f7b init_vp_index() has\n\"const uuid_le *type_guid\" already. And somewhere between commit\nd3ba720dd58cdf6630fee4b89482c465d5ad0d0f and the one above the \"const\"\nwas added. But git log does not show this commit.\n\nWhy is that so, and whats the command to really show all and every change?\n\nOlaf\n"},{"id":"266104","messageId":"20150714074508.GE1451@serenity.lan","threadId":"39846","inReplyTo":"20150714073035.GA22707@aepfle.de","subject":"Re: git log fails to show all changes for a file","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2015-07-14T07:45:08Z","receivedAt":"2015-07-14T07:45:08Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jul 14, 2015 at 09:30:35AM +0200, Olaf Hering wrote:\n> \n> I wonder why this command fails to show all commits that modify a given\n> function: \n> \n> linux.git $ git log -p -M --stat -- drivers/hv/channel_mgmt.c\n> \n> With commit 1f656ff3fdddc2f59649cc84b633b799908f1f7b init_vp_index() has\n> \"const uuid_le *type_guid\" already. And somewhere between commit\n> d3ba720dd58cdf6630fee4b89482c465d5ad0d0f and the one above the \"const\"\n> was added. But git log does not show this commit.\n> \n> Why is that so, and whats the command to really show all and every change?\n\nIt was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),\ntry:\n\n\tgit log -p -M --stat --cc -- drivers/hv/channel_mgmt.c\n"},{"id":"266105","messageId":"20150714075955.GA24577@aepfle.de","threadId":"39846","inReplyTo":"20150714074508.GE1451@serenity.lan","subject":"Re: git log fails to show all changes for a file","fromName":"Olaf Hering","fromEmail":"olaf@aepfle.de","sentAt":"2015-07-14T07:59:55Z","receivedAt":"2015-07-14T07:59:55Z","isPatch":false,"sender":{"key":"olaf@aepfle.de","avatar":"https://avatars.githubusercontent.com/u/942324?v=4"},"body":"On Tue, Jul 14, John Keeping wrote:\n\n> It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),\n> try:\n> \n> \tgit log -p -M --stat --cc -- drivers/hv/channel_mgmt.c\n\nThanks. Thats rather useless output...\n\n@@@ -404,7 -365,7 +404,7 @@@ static u32 next_vp\n * performance critical channels (IDE, SCSI and Network) will be uniformly\n * distributed across all available CPUs.\n */\n- static void init_vp_index(struct vmbus_channel *channel, uuid_le *type_guid)\n -static u32 get_vp_index(const uuid_le *type_guid)\n++static void init_vp_index(struct vmbus_channel *channel, const uuid_le *type_guid)\n {\n u32 cur_cpu;\n int i;\n\n\nOlaf\n"},{"id":"266135","messageId":"87615maam6.fsf@igel.home","threadId":"39846","inReplyTo":"20150714075955.GA24577@aepfle.de","subject":"Re: git log fails to show all changes for a file","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2015-07-14T17:54:09Z","receivedAt":"2015-07-14T17:54:09Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Olaf Hering writes:\n\n> On Tue, Jul 14, John Keeping wrote:\n>\n>> It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),\n>> try:\n>> \n>> \tgit log -p -M --stat --cc -- drivers/hv/channel_mgmt.c\n>\n> Thanks. Thats rather useless output...\n\nWhy do you think this is useless?\n\n> @@@ -404,7 -365,7 +404,7 @@@ static u32 next_vp\n> * performance critical channels (IDE, SCSI and Network) will be uniformly\n> * distributed across all available CPUs.\n> */\n> - static void init_vp_index(struct vmbus_channel *channel, uuid_le *type_guid)\n> -static u32 get_vp_index(const uuid_le *type_guid)\n> ++static void init_vp_index(struct vmbus_channel *channel, const uuid_le *type_guid)\n\nOne branch renamed get_vp_index to init_vp_index, the other branch added\nthe const attribute. This hunk combines both changes.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"266139","messageId":"CA+55aFzPvwAghGtA-WH8i1PcNe55XORokaXF9hNu7OUXBx++6Q@mail.gmail.com","threadId":"39846","inReplyTo":"20150714075955.GA24577@aepfle.de","subject":"Re: git log fails to show all changes for a file","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2015-07-14T19:16:48Z","receivedAt":"2015-07-14T19:16:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Jul 14, 2015 at 12:59 AM, Olaf Hering wrote:\n> On Tue, Jul 14, John Keeping wrote:\n>\n>> It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),\n\nThat's not an evil merge. That's just a regular merge. One side had\nchanged the argument to \"const\":\n\n - 1b9d48f2a579 (\"hyper-v: make uuid_le const\")\n\nwhile the other side had renamed the function and added an argument,\nand changed the return type:\n\n - d3ba720dd58c (\"Drivers: hv: Eliminate the channel spinlock in the\ncallback path\")\n\nan \"evil merge\" is something that makes changes that came from neither\nside and aren't actually resolving a conflict.\n\nThat said, I do wonder if we should just make \"-p\" imply \"--cc\". Right\nnow we have the kind of odd situation that \"git log -p\" doesn't show\nmerge patches, but \"git show \" does show them. And you kind of\nhave to know a lot about git to know the \"--cc\" option.\n\nIn fact, that \"git show\" behavior really is very subtle, but very\nuseful. It comes from show_rev_tweak_rev(), which is a magic git-show\nthing.\n\n Linus\n"},{"id":"266153","messageId":"xmqq8uahxu3e.fsf@gitster.dls.corp.google.com","threadId":"39846","inReplyTo":"CA+55aFzPvwAghGtA-WH8i1PcNe55XORokaXF9hNu7OUXBx++6Q@mail.gmail.com","subject":"Re: git log fails to show all changes for a file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-15T16:29:25Z","receivedAt":"2015-07-15T16:29:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That said, I do wonder if we should just make \"-p\" imply \"--cc\". Right\n> now we have the kind of odd situation that \"git log -p\" doesn't show\n> merge patches, but \"git show \" does show them. And you kind of\n> have to know a lot about git to know the \"--cc\" option.\n>\n> In fact, that \"git show\" behavior really is very subtle, but very\n> useful. It comes from show_rev_tweak_rev(), which is a magic git-show\n> thing.\n\nI would think \"git log -p\" that implies \"--cc\" would be a good\nchange, as long as there is an easy escape hatch to let us do what\nwe have to do with a rather lengthy \"git log -p --first-parent -m\"\n(i.e. show the change relative to its first parent while traversing\nthe first parent chain) today. Perhaps only when there is no\nexplicit \"-m\" but \"-p\" is given, automatically enable \"--cc\", or\nsomething like that.\n"},{"id":"266154","messageId":"CA+55aFy8urE+0w7mfgywcAnyoUu+6LMz-GGaOrUQYJ59gT9FfA@mail.gmail.com","threadId":"39846","inReplyTo":"xmqq8uahxu3e.fsf@gitster.dls.corp.google.com","subject":"Re: git log fails to show all changes for a file","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2015-07-15T17:13:12Z","receivedAt":"2015-07-15T17:13:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano wrote:\n>\n> I would think \"git log -p\" that implies \"--cc\" would be a good\n> change, as long as there is an easy escape hatch to let us do what\n> we have to do with a rather lengthy \"git log -p --first-parent -m\"\n> (i.e. show the change relative to its first parent while traversing\n> the first parent chain) today. Perhaps only when there is no\n> explicit \"-m\" but \"-p\" is given, automatically enable \"--cc\", or\n> something like that.\n\nThat's very close to what \"git show\" does through that magic\nshow_rev_tweak_rev() logic, with the crucial difference being that\n\"git show\" is designed to always show the diff, so the \"-p\" is\nimplied.\n\nThat said, having thought about it more, I'm not entirely sure we can\ndo it. The big conceptual difference between \"git log\" and \"git show\"\nis obviously that \"git show\" doesn't walk the revision list, and you\nalways explicitly say \"show _this_ commit\".\n\nAnd that means that with \"git show\", you kind of _know_ that the\ncommit is relevant and interesting, in a way that \"git log\" does not.\nSo got \"git show\", it's very natural to say \"show all the relevant\ninformation\", while for \"git log\" we did make the choice that maybe\ncommit diffs aren't relevant by default.\n\nAnd the whole issue ends up boiling down to \"maybe we picked the wrong\nchoice default\". We default to that \"ignore_merges = 1\" behavior.\n\nNow, we defaulted to ignoring merge diffs because long long ago, in a\ngalaxy far away, we didn't have a great way to show the diffs. The\nwhole \"--cc\" option goes back to January -06 and commit d8f4790e6fe7\n(\"diff-tree --cc: denser combined diff output for a merge commit\") .\nAnd before that option - so for about 8 months - we had no good way to\nshow the diffs of merges in a good dense way.\n\nSo the whole \"don't show diffs for merges by default\" actually made a\nlot of sense originally, because our merge diffs were not very useful.\n\nBut that does mean that if we now enable \"--cc\" by default when you\nask for diffs, we have no good way to _disable_ it. We picked \"disable\nby default\", and \"-m\" means \"enable merge diffs\". And that made sense\nback in 2005 because we really wanted to disable the whole \"show diffs\nfor merges\" thing.\n\nOf course, you can use \"--no-merges\" to basically not show merges at\nall, so maybe that's ok. But I get the feeling that if we make \"-p\"\nimply \"--cc\", we should probably add a \"--no-merge-diff\" option too to\nreplace the (broken) \"-m\" flag properly. And I'm a tiny bit worried\nthat it might break some script (although I'm really not seeing\nhow/why you'd script \"git log -p\" output and not want to get a --cc\npatch for a merge).\n\nAnd \"-m\"? We should probably get rid of it. The diffs we get for\nmerges when \"-c\" or \"--cc\" isn't given are _not_ useful. The original\nnon-combined diff format was really just useful for showing that\n\"yeah, we have multiple parents, and they are different in all these\nways\". So there is no actual valid use for \"-m\" that I can imagine.\nIt's simply just an odd historical artifact from a time when we didn't\nknow how to show merges.\n\n Linus\n"},{"id":"266155","messageId":"xmqqy4ihwbdr.fsf@gitster.dls.corp.google.com","threadId":"39846","inReplyTo":"CA+55aFy8urE+0w7mfgywcAnyoUu+6LMz-GGaOrUQYJ59gT9FfA@mail.gmail.com","subject":"Re: git log fails to show all changes for a file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-15T17:58:56Z","receivedAt":"2015-07-15T17:58:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> ...\n> So the whole \"don't show diffs for merges by default\" actually made a\n> lot of sense originally, because our merge diffs were not very useful.\n\nI agree with most of your analysis of the history, but not with \"-m\"\n(rather, a part of what \"-m\" does).\n\n> And \"-m\"? We should probably get rid of it. The diffs we get for\n> merges when \"-c\" or \"--cc\" isn't given are _not_ useful. The original\n> non-combined diff format was really just useful for showing that\n> \"yeah, we have multiple parents, and they are different in all these\n> ways\". So there is no actual valid use for \"-m\" that I can imagine.\n\nWhen combined with \"--first-parent\" it is a way to view what the\nmerge brought in from a side branch.\n\n $ git log --first-parent -m -p ko/master..master\n\nis something I do every time I merge a batch of topics to the\n'master' branch (where ko/master keeps track of what was pushed\nto k.org the last time).\n\nThe fact that \"-m\" shows diffs with each and every parent is an odd\nhistorical behaviour, and the only justification for it is that\npeople might want to view differences with second and later parents,\nwhich is weak, and one way to allow them to view differences with\nlater parents is to show all (and force people to skip them in\nnormal use case), which is even weaker.\n\nSo to be constructive and to pu a different proposal on the table,\nhow about aiming for this end-game state?\n\n * When '-p' is given, we show only diff with first-parent by\n default, regardless of the traversal (i.e. --first-parent option\n currently controls both traversal and patch display, but in the\n new world order, it reverts back to purely a traversal option).\n\n * We could allow you to say '-p -m2' to get second-parent diff for\n merges, but I do not think we should bother, for at least two\n reasons. It opens a can of worms, like \"what should '-p -m4' to\n for a two-parent merge?\" Also \"log\" unlike \"show\" is about many\n commits, and I do not think of a reason why you would want a\n series of diff between the side-branch tip and the result. '-m2'\n would only be useful for commits that was made by mistake,\n merging the trunk into a side branch, swapping the\n first-parenthood, which ought to be rare.\n\n * If somebody wants to omit patch for merges, while still showing\n the merge log, use '-p --no-show-merge-diff'.\n\n * When people want '--cc' or '-c', they can with 'log -p --cc',\n just like today. We might want to make '--cc' imply '-p', but I\n vaguely recall some discussion against this [*2*].\n\nTransition plan is a separate matter.\n\n\n[Footnotes]\n\n*1* With modern Git if you were pushing only to a single\n destination, you could say master@{push} instead, but I do not\n have remote.origin in my repository and push to multiple places,\n so master@{push} does not resolve ;-)\n\n*2* http://thread.gmane.org/gmane.comp.version-control.git/215341/focus=215470\n"},{"id":"266157","messageId":"CA+55aFw=PJtc7jXLUx+tJhAeVO3vpQjsd+oYW+OwCU20_Qft-w@mail.gmail.com","threadId":"39846","inReplyTo":"xmqqy4ihwbdr.fsf@gitster.dls.corp.google.com","subject":"Re: git log fails to show all changes for a file","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2015-07-15T18:11:32Z","receivedAt":"2015-07-15T18:11:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano wrote:\n>\n> * When '-p' is given, we show only diff with first-parent by\n> default, regardless of the traversal (i.e. --first-parent option\n> currently controls both traversal and patch display, but in the\n> new world order, it reverts back to purely a traversal option).\n\nSo this is a suggested change to \"-p -m\" behavior?\n\nYes, that sounds sane. The current \"-p -m\" behavior is not useful at all.\n\nSo if I understand rightly, we'd have:\n\n \"-p\" would be what is currently \"-p --cc\"\n \"-p -m\" would be what is currently \"-p --first-parent\"\n \"-p --no-show-merge-diffs\" would be what is currently \"-p\"\n\nand the rationale would be that\n\n (a) the current \"-p\" is hiding things, and while you can add \"--cc\",\nthat requires that you really understand what is being hidden, which\nis a bad default (the complaint that started this discussion)\n\n (b) the current \"-p -m\" is useless crazy stuff, and you'd rather use\nit for something that you actually find very common and useful\n\nIf so, I agree entirely.\n\n Linus\n"},{"id":"266158","messageId":"xmqqtwt5wai9.fsf@gitster.dls.corp.google.com","threadId":"39846","inReplyTo":"CA+55aFw=PJtc7jXLUx+tJhAeVO3vpQjsd+oYW+OwCU20_Qft-w@mail.gmail.com","subject":"Re: git log fails to show all changes for a file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-15T18:17:50Z","receivedAt":"2015-07-15T18:17:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano wrote:\n>>\n>> * When '-p' is given, we show only diff with first-parent by\n>> default, regardless of the traversal (i.e. --first-parent option\n>> currently controls both traversal and patch display, but in the\n>> new world order, it reverts back to purely a traversal option).\n>\n> So this is a suggested change to \"-p -m\" behavior?\n\nNot really. This is a suggested behaviour for \"git log -p\"; I\nwasn't very enthused by the idea to turn --cc when user said -p\nwithout telling them what we are doing. In other words, if the\nusers want combined, they should say --cc (and they will get a\nsingle-parent patch for non-merges with --cc) so there is no reason\nnot to do this, as long as we fix --cc so that \"git log --cc\"\nimplies \"git log --cc -p\".\n\n> Yes, that sounds sane. The current \"-p -m\" behavior is not useful at all.\n>\n> So if I understand rightly, we'd have:\n>\n> \"-p\" would be what is currently \"-p --cc\"\n\nNot really.\n\n> \"-p -m\" would be what is currently \"-p --first-parent\"\n\nNot really. I was dropping \"-m\" entirely with \"we could do -p -m2\nbut I do not think we should bother\".\n\n> \"-p --no-show-merge-diffs\" would be what is currently \"-p\"\n\nYes.\n\n> and the rationale would be that\n>\n> (a) the current \"-p\" is hiding things, and while you can add \"--cc\",\n> that requires that you really understand what is being hidden, which\n> is a bad default (the complaint that started this discussion)\n>\n> (b) the current \"-p -m\" is useless crazy stuff, and you'd rather use\n> it for something that you actually find very common and useful\n>\n> If so, I agree entirely.\n>\n> Linus\n"},{"id":"266159","messageId":"20150715185717.GA11146@peff.net","threadId":"39846","inReplyTo":"xmqqtwt5wai9.fsf@gitster.dls.corp.google.com","subject":"Re: git log fails to show all changes for a file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-07-15T18:57:18Z","receivedAt":"2015-07-15T18:57:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote:\n\n> > So this is a suggested change to \"-p -m\" behavior?\n> \n> Not really. This is a suggested behaviour for \"git log -p\"; I\n> wasn't very enthused by the idea to turn --cc when user said -p\n> without telling them what we are doing. In other words, if the\n> users want combined, they should say --cc (and they will get a\n> single-parent patch for non-merges with --cc) so there is no reason\n> not to do this, as long as we fix --cc so that \"git log --cc\"\n> implies \"git log --cc -p\".\n\nLike you, I frequently use \"--first-parent -m\". If I understand your\nproposal, a regular \"git log\" would have the first-parent-diff behavior\nof those options, but still traverse other parents.\n\nOne oddity of that proposal is that the user ends up seeing any given\nchange on a side-branch _twice_. Once in the original commit that\nintroduced it, and once in the merge of the branch. And commit-selection\ntools like \"git log -Ssome_code\" will select both, too, and they'll see\nthe merge commit along with the original. I can't decide if that's a\ngood thing or not.\n\n-Peff\n"},{"id":"266160","messageId":"CA+55aFyMq1VjFcpa4kAy9XBuntHWr-aCeKr9JdxuK5kt=Z1pRw@mail.gmail.com","threadId":"39846","inReplyTo":"xmqqtwt5wai9.fsf@gitster.dls.corp.google.com","subject":"Re: git log fails to show all changes for a file","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2015-07-15T19:17:28Z","receivedAt":"2015-07-15T19:17:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Jul 15, 2015 at 11:17 AM, Junio C Hamano wrote:\n>>\n>> So this is a suggested change to \"-p -m\" behavior?\n>\n> Not really. This is a suggested behaviour for \"git log -p\"\n\nOh, in that case I say NAK NAK NAK.\n\nThat would be totally horrible, and completely unacceptable.\n\nI do \"git log -p\" all the time, and merge-diffs with --first-parent\nare regularly hundreds of thousands of lines for the kernel.\n\nSo no. That is COMPLETELY unacceptable. Not even worth discussing.\n\n Linus\n"},{"id":"266161","messageId":"xmqqpp3tw7if.fsf@gitster.dls.corp.google.com","threadId":"39846","inReplyTo":"20150715185717.GA11146@peff.net","subject":"Re: git log fails to show all changes for a file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-15T19:22:32Z","receivedAt":"2015-07-15T19:22:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote:\n>\n>> > So this is a suggested change to \"-p -m\" behavior?\n>> \n>> Not really. This is a suggested behaviour for \"git log -p\"; I\n>> wasn't very enthused by the idea to turn --cc when user said -p\n>> without telling them what we are doing. In other words, if the\n>> users want combined, they should say --cc (and they will get a\n>> single-parent patch for non-merges with --cc) so there is no reason\n>> not to do this, as long as we fix --cc so that \"git log --cc\"\n>> implies \"git log --cc -p\".\n>\n> Like you, I frequently use \"--first-parent -m\". If I understand your\n> proposal, a regular \"git log\" would have the first-parent-diff behavior\n> of those options, but still traverse other parents.\n>\n> One oddity of that proposal is that the user ends up seeing any given\n> change on a side-branch _twice_. Once in the original commit that\n> introduced it, and once in the merge of the branch. And commit-selection\n> tools like \"git log -Ssome_code\" will select both, too, and they'll see\n> the merge commit along with the original. I can't decide if that's a\n> good thing or not.\n\nHmm, you are right. That may be a problem, and Linus's makes tons\nof practical sense (especially for us experienced Git users).\n\nIt just is that '-p', that clearly stands for 'patch' but does more\nthan 'patch' to produce something that cannot be fed to 'apply' by\ndefaulting to '--cc', makes me hesitate. By making it a lot more\nconvenient for experienced people who understand these issues, I\nhave this suspicion that it would make the options less orthgonal\nand harder to explain to new people.\n"}]}