On Tue, Jul 12, 2011 at 5:07 PM, Clemens Buchacher <drizzd@xxxxxx> wrote: [snip] > Now, one might argue that this is a corner case. But it's actually > very common. In the example, the patch-id changes because of an > extra change in a different text area. That is indeed unlikely. > However, the same problem will occur in a much more common case. > Let's say we have a patch with 10 hunks. The patch is applied > upstream, with only one difference in one of the hunks. > Subsequently, text areas affected by any of the other hunks change > upstream. When the original patch is rebased on top of that, it > will conflict with the one hunk that was changed in the upstream > version of that patch. And that's ok. Git should not decide which > version is correct. But in addition to that conflict there will > also be conflicts for all the other hunks, which the upstream patch > did _not_ modify. And all of those conflicts will look like > reverts. > > I believe that is the main reason why rebase is so painful all the > time. Clemens, that's a great description of the problem. I've run into this several times, and it is really confusing. I've spent considerable time tracking down the real conflict... only to find the real issue was in something non-related and easily resolved. IMHO, I agree with you Clemens: this has been my major source of pain. -John -- 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