Karl Hasselström wrote:
If I make a patch series where more than one patch touches the same line, I get a lot of merge errors when upstream has accepted them and I try to merge them back. Suppose a line contained the string "0". Patch p1 changes that to "1", patch p2 further changes that to "2". Upstream accept the patches, and I later "stg pull" them. When reapplying p1 after the pull, stg generates a merge conflict since upstream changed the "0" to "2" and p1 changes the "0" to "1". This situation arises for every line that's modified in more than one patch, and for every such patch except the last one. And it's really annoying, since it's intuitively obvious that there aren't actually any conflicts, since upstream accepted my patches verbatim. I suppose one way to fix it manually would be to first fetch, glance at the new upstream commits and try to find any accepted patches, and then "stg pull" the commit corresponding to the earliest patch in my series; repeat for every patch in the series. The queston is, how can we automate it?
I don't seem to suffer from this, using my "diff3 || ediff-merge-files-with-ancestor" script as a merge tool. The diff3, or ediff, seem to DTRT so long as the change is cleanly applied. Otherwise I just get a merge conflict difference and I just press A/B to pick which one I want.
Sam. - : 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