[squeak-dev] Monticello merge - what does Keep/Reject mean again?

Eliot Miranda eliot.miranda at gmail.com
Sun Jan 24 16:36:48 UTC 2016

> On Jan 24, 2016, at 4:21 AM, Jakob Reschke <jakob.reschke at student.hpi.de> wrote:
> For completeness sake, let me add how other tools call their options.
> In git, the nearest equivalent to these buttons would be "ours" and
> "theirs" as a merge strategy, "local" and "remote" in the mergetool
> pre-resolution overview and HEAD and to-be-merged-branch's-name in the
> diff. The latter could read like working copy and
> to-be-merged-version's-name in Monticello. Mercurial apparently calls
> them "local" and "other". SVN calls them "mine" and "theirs".
> If the diff display were not unified in Monticello, you could call one
> version "left" and the other "right" and name the buttons after them.
> Kdiff3 calls them A, B and C in a three-way merge and you "choose A",
> for example. Now that the diff is unified and colored, it would be
> possible to "choose red" or "choose blue" and easily match that up
> with what you see. But especially now that the interest in themes came
> up again, the colors might be changed.
> IMHO the designation of the origin
> (local/remote/mine/ours/theirs/other) should be added to the buttons.
> The verb then becomes less important which is good, because apparently
> there are different perspectives on the operation. Also, the other
> tools mentioned above all name the options after their origin, so it
> may be easier for newcomers if Monticello did so as well. If we
> include a verb, my personal favourites would be "keep local" and
> "accept/use remote" (in that order, which would mean to swap the
> buttons, but I understand if that is rejected).

Thanks Jakob.  I didn't think of nouns, only verbs.  I like "Mine" or "Ours" vs "Theirs".

> 2016-01-23 17:37 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>> Hi Fabio, Chris,
>> On Jan 22, 2016, at 4:00 PM, Fabio Niephaus <lists at fniephaus.com> wrote:
>> I think that it's not only the naming but also the direction that is
>> confusing. Sorry for being selfish, but I usually care about my own stuff
>> more than about the stuff on the server, right?
>> How about:
>>  Keep -> 'Replace Local'
>>  Reject -> 'Keep Local'
>> Let's try and search for more candidates.  The two word ones are clunky and
>> long.  Keep is horrible because it conflicts with the sense of "keep what's
>> mine".  But some other duals are (where left is Replace Local and right is
>> Keep Local)
>> Import vs Exclude
>> Accept vs Reject
>> Merge vs Ignore
>> Advance vs Remain
>> Approve vs Disapprove
>> More of a stretch but may trigger thought:
>> Infect vs Quarantine
>> Ingest vs Refuse
>> and the question mark at the end of each suggestion is implicit ;-)
>> Any other suggestions?
>> This is also what most syncing services name the two options when you
>> start using them (e.g. iCloud or Google Chrome Sync).
>> Best,
>> Fabio
>> --
>> On Fri, Jan 22, 2016 at 11:41 PM Chris Cunningham <cunningham.cb at gmail.com>
>> wrote:
>>> So, once again, I am bitten by these button labels.  They just don't speak
>>> to me.
>>> From back in 2013, there was a description by Nice that explained it thus:
>>> "If you say keep, then you accept the incoming version to replace your
>>> version.
>>> If you say reject, then refuse the incoming version and prefer to keep
>>> your own version."
>>> Then back in 2015, another discussion about what these values mean with
>>> several options thrown out.  But it looks like we still have Keep and Reject
>>> - which still confuses me.
>>> Maybe we could just relabel them the way Nice suggested:
>>>    Keep -> 'Keep Incoming'
>>>    Reject -> 'Reject Incoming'
>>> ?  Maybe also update the balloon help to take Nice's exact words?
>>> I'll push a change later tonight/tomorrow to the InBox unless I hear back
>>> that this is a horrible idea.
>>> Thanks,
>>> cbc

More information about the Squeak-dev mailing list