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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Feb 28 08:46:18 2006
This archive was generated by hypermail 2.1.8 : 2006-02-28 08:46:30 EST