Please don't set Mail-Followup-To; it's disliked on this list. Am 1/26/2011 9:36, schrieb Francis Moreau: > I tried to reproduce something similar but with a far more simple repo: > > > <v2.6.28> 1.f o > | > 1.e o (merge) > | \ > 1.d o o 2.c (merge) > | | \ > 1.c o o o 3.a "Remove blacklist_iommu()" > | | / > | o 2.a > | / > 1.b o > | > <v2.6.27> 1.a o "Introduce blacklist_iommu()" > | > o Init > > Basically this repo 3 branches: master, 2, 3. Master branch introduces > the "blacklist_iommu()" function with commit 1.a, and branch "3" removes > it at commit 3.a. > ... > So in this case there's no need to pass the '-m' flag and git-log(1), by > default walks through all the commits: To reproduce the real history, you have to modify your example in three ways: 1. 2.a must be forked off of Init, not 1.b; i.e., this commit does not contain "blacklist_iommu". 2. Drop the side branch that removes the word. (Drop at least the commit.) 3. The merge 1.e (which resembles d847059) must be modified such that it takes the contents of 2.c rather than 1.d. IOW, "blacklist_iommu" is not removed explicitly by a commit, but rather by a merge of one branch that has it and another one that doesn't have it. Look closely at d847059: The commit message hints at a conflict in intel_iommu.c, and Ingo resolved the conflict by taking the contents of the file of one branch, namely the branch that does *not* contain "blacklist_iommu", ignoring entirely what happend on the other branch (that had added "blacklist_iommu" somewhere at or before v2.6.27). -- Hannes -- 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