[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
From: |
David Kastrup |
Subject: |
Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful |
Date: |
Wed, 27 Nov 2013 21:54:02 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>> Whenever you use _meaning_-carrying names, they'll be wrong half of the
>> time. Ediff got that right with A, B, and, uh, C? No idea (rarely use
>> three-way conflicts). It's arbitrary what the first and the second
>> _mean_, so you just put them first and second on screen and give them A
>> and B as monikers.
>
> For three-way merges, the 3rd is called "BASE" in smerge, which makes
> sense, no matter how you get that result. Using A/B/Base is not great
> because of the conflicting first letter of B and Base.
> Maybe we could go with X/Y/Base?
Well, I don't see why "BASE" needs to have a meaning-carrying name while
the others don't, but it could be "C" for "Common ancestor". Or "R" for
"Root". But the latter is probably a really bad idea in connection with
ediff bindings.
--
David Kastrup
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, (continued)
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, David Kastrup, 2013/11/23
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, Stefan Monnier, 2013/11/25
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, David Kastrup, 2013/11/27
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, Stefan Monnier, 2013/11/27
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, David Kastrup, 2013/11/27
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, David Kastrup, 2013/11/27
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, Stefan Monnier, 2013/11/27
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, Thien-Thi Nguyen, 2013/11/28
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful, Stefan Monnier, 2013/11/28
- Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful,
David Kastrup <=