Re: Automatic 3 way merge for conflicts

[louis <louis obsidian com au>]

Thanks for the suggestions,

I've cleaned this up, and it's been implemented for git, bzr and svn. Patch attached.

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.

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.

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)

Cheers,

--
Louis

On 16 December 2012 07:54, Kai Willadsen <kai willadsen gmail com> wrote:

On 11 December 2012 14:14, louis <louis obsidian com au> wrote:
> A nice feature which I feel should be possible here is when opening a file
> which is listed by VC as conflicted, that it is opened in a 3 way merge as
> OTHER/MERGE HEAD | merged | THIS/HEAD
>
> So I wipped up this as a proof of concept for bzr and git, thought I'd get
> some feedback before I clean it up properly.

Very nice!

I do have to caution you that ideally this will be done (and changed)
in my in-progress history comparison branch... but since that may be a
while off yet, if you're keen to try and get this in, then I certainly
have no objections.

> Perhaps a different argument to get_path_for_repo_file than conflict...

While the logic is similar, it does feel weird to re-use
get_path_for_repo_file  I think the thing is that the horribly-named
get_path_for_repo_file is about grabbing a file at a *revision*,
whereas this is about grabbing a file in a *state*. Maybe the
distinction is smaller in reality than in my head, but I'd prefer it
split out to a separate function entirely I think.

> and
> perhaps something better than string comparisons should be used (I've used
> bzr style OTHER/BASE/THIS in this patch) but it works for me  as is :D

So I think it would be much more sane to have some constants in _vc
for this. As a git user, of course I want BASE/LOCAL/REMOTE/MERGED...
but as long as they're sane, we can rename later if desired.

cheers,
Kai

Attachment: meld-3-way-merge.patch
Description: Binary data