Jeff King <peff@xxxxxxxx> writes: > On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote: > >> > So this is a suggested change to "-p -m" behavior? >> >> Not really. This is a suggested behaviour for "git log -p"; I >> wasn't very enthused by the idea to turn --cc when user said -p >> without telling them what we are doing. In other words, if the >> users want combined, they should say --cc (and they will get a >> single-parent patch for non-merges with --cc) so there is no reason >> not to do this, as long as we fix --cc so that "git log --cc" >> implies "git log --cc -p". > > Like you, I frequently use "--first-parent -m". If I understand your > proposal, a regular "git log" would have the first-parent-diff behavior > of those options, but still traverse other parents. > > One oddity of that proposal is that the user ends up seeing any given > change on a side-branch _twice_. Once in the original commit that > introduced it, and once in the merge of the branch. And commit-selection > tools like "git log -Ssome_code" will select both, too, and they'll see > the merge commit along with the original. I can't decide if that's a > good thing or not. Hmm, you are right. That may be a problem, and Linus's makes tons of practical sense (especially for us experienced Git users). It just is that '-p', that clearly stands for 'patch' but does more than 'patch' to produce something that cannot be fed to 'apply' by defaulting to '--cc', makes me hesitate. By making it a lot more convenient for experienced people who understand these issues, I have this suspicion that it would make the options less orthgonal and harder to explain to new people. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html