[Python-Dev] Hg tips

[Xavier Morel]

On 2011-09-29, at 12:50 , Victor Stinner wrote:
> Le 29/09/2011 12:34, Xavier Morel a écrit :
>> Generally none. By default, mercurial (and most similar tools) sets up LOCAL, BASE and OTHER. BASE is the...
> 
> Sorry, but I'm unable to remember the meaning of LOCAL, BASE and OTHER. In meld, I have to scroll to the end of the filename so see the filename suffix. Anyway, my real problem was different: hg opened meld with the 3 versions, but the BASE was already merged. I mean that hg chose for me what is the right version, without letting me choose myself what is the good version, because if I just close meld, I lose my local changes.
I'd bet it's Meld doing that, though I have not checked (Araxis Merge does something similar, it has its own merge-algorithm which it tries to apply in case of 3-ways merge, trying to merge LOCAL and OTHER into base on its own).

Look into Meld's configuration, it might be possible to disable that.

(an other possibility would be that the wrong file pointers are send to Meld, so it gets e.g. twice the same file)

> Because a merge is a new commit, I suppose that I can do something to get my local changes back. But, well, I just prefer the "legacy" (?) merge flavor:
> 
> <<<< local
> ...
> ===
> ...
> >>> other
> 
> It's easier for my brain because I just have 2 versions of the same code, not 3!
> 
> But it looks like some people are more confortable with 3 versions in a GUI, because it is the default Mercurial behaviour (to open a GUI to solve conflicts).
> 
I'd be part of that camp, yes (though I'll use either depending on the exact situation, there are cases where seeing what both branches diverged from is very useful). I find having all three version makes it easier to correctly mix the two diverging versions, with /usr/bin/merge-style conflict markers it's harder to understand what both branches diverged from and hence how their changes fit into one another.