On Wed, Aug 31, 2011 at 7:18 AM, Julian Foad <julian.f...@wandisco.com>wrote:
> On Tue, 2011-08-30 at 18:00 +0100, Philip Martin wrote: > > Paul Burba <ptbu...@gmail.com> writes: > > > > > Could you provide some examples of when 'things start to go wrong when > > > you next try to use "automatic" merges between the branches'? Was > > > there a particular use-case (or cases) you had in mind, or just a > > > general sense that maybe this is/could be a problem? > > > > Here's one (shorter recipes are possible): > > Yes, this is exactly the sort of thing I mean. What I expect in general > is that if I have merged the same change into both branches, then an > automatic (catch-up) merge would do nothing with that particular change. > But here we reverse-merge the same change into both branches, and then a > catch-up merge raises a conflict on that change. > Wouldn't that be entirely expected given the cyclic merge problem? You made a change in the source branch and committed it. Instead of merging that commit to the target branch as you would any other change, you made the same change on the target branch. But when you synch the target with the source it is of course going to still try to merge this same change and create a conflict. In at least this specific scenario, I do not think the reverse merge is relevant. Suppose it is just a bug fix. You make the fix in the source. You are supposed to merge that to the branch. If you instead make the same fix in the branch, as opposed to merging the fix, then it would be expected that you get a conflict later when you synch merge. As long as the merge algorithm is based on merging revisions, I do not see how you change this. -- Thanks Mark Phippard http://markphip.blogspot.com/
