Re: Automatic 3 way merge for conflicts



On 17 December 2012 16:50, louis <louis obsidian com au> wrote:
> Thanks for the suggestions,
> I've cleaned this up, and it's been implemented for git, bzr and svn. Patch
> attached.

We should probably take this to bugzilla; can you open up a new bug
for this please, and attach your patches?

Brief comments on the patch, since I don't really have time right now
for a full review:
 * Could you split out the enhancements that aren't related to the
merge stuff into a separate patch? For instance, it would be very easy
for me to test and apply the bzr get_path_for_repo_file() support.
 * The Subversion changes scare me. Unless it's absolutely necessary
and very well tested, I'd rather not rip out that code on a whim. And
as far as I can tell, those changes aren't necessary for the feature.

> One remaining possibility is to compare to BASE instead of MERGED, but for
> all the above systems when a conflict is encountered, the main file has the
> merge markers inserted. This means that unless we replace this file with
> BASE when we start the comparison, we are no longer editing in place, and
> it's not as helpful.

As I mentioned in the other email on this thread, I think that what we
actually want is MERGED with diff3 conflict markers, and we replace
the whole conflict with the section between |||||||| and ========. I
haven't actually tried this yet, so I'm just guessing as to the most
useful thing.

> I was going to look at hg, but seems that meld doesn't even recognize hg
> conflicts yet anyway (they aren't shown by status) so I'll leave that one
> for when the history comparison branch is done.

We don't... well, that's weird. I'll try to take a look at this sometime soon.

> As for that branch - happy to lend a hand if there are any distinct chunks
> which can be split off, but probably better discussed off list (feel free to
> contact me directly)

Thanks. Unfortunately, the difficulty is in working through Meld's
assumptions about buffers being mappable to files and all sorts of
irritating subtleties. The actual code is relatively small, and most
of the difficulty is in UI and API decisions. I'll try and make the
branch available as soon as I think it's useful to do so.

cheers,
Kai


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]