On 2008.08.22 10:51:36 -0700, Andrew Morton wrote:Alan provided his bisection log as an attachment to the original bug report. Yep, and that's totally correct as far as bisect is concerned. The parents of that merge commit are: 88fa08f67bee1a0c765237bdac106a32872f57d2 b1b135c8d619cb2c7045d6ee4e48375882518bb5 And Alan marked both of them as good. So, unless Alan made a mistake during his bisection, each of the branches is correct, but the merge did not lead to a correct result. So while there were no textual conflicts, there were still incompatible changes regarding the code semantics and compatibility was not restored during the merge. To get an overview over what got merged together you can can use something like: gitk --left-right 1c89ac55017^1...1c89ac55017^2 Which shows all commits that were on only one side of the merge, with nice "arrows" that indicate from which side the commit is coming. The conflict should be between one commit from the left and one commit from the right side, obviously. Björn --
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Tomasz Kłoczko | Is it time for remove (crap) ALSA from kernel tree ? |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Paweł Staszewski | iproute2 action/policer question |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
