From: Sam Vilain <sam@vilain.net>
Date: Mon, 27 Feb 2006 21:45:34 GMT
Subject: Re: bug?: stgit creates (unneccessary?) conflicts when pulling
Message-ID: <440372FE.2000301@vilain.net>
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>

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.