<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"></div></div></div>
<br><br><div class="gmail_quote">On Sun, Jan 24, 2016 at 1:21 PM, Jakob Reschke <span dir="ltr"><<a href="mailto:jakob.reschke@student.hpi.de" target="_blank">jakob.reschke@student.hpi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For completeness sake, let me add how other tools call their options.<br>
In git, the nearest equivalent to these buttons would be "ours" and<br>
"theirs" as a merge strategy, "local" and "remote" in the mergetool<br>
pre-resolution overview and HEAD and to-be-merged-branch's-name in the<br>
diff. The latter could read like working copy and<br>
to-be-merged-version's-name in Monticello. Mercurial apparently calls<br>
them "local" and "other". SVN calls them "mine" and "theirs".<br>
<br>
If the diff display were not unified in Monticello, you could call one<br>
version "left" and the other "right" and name the buttons after them.<br>
Kdiff3 calls them A, B and C in a three-way merge and you "choose A",<br>
for example. Now that the diff is unified and colored, it would be<br>
possible to "choose red" or "choose blue" and easily match that up<br>
with what you see. </blockquote><div><br></div><div>So we could have Blue pill and Red pill ? :-)</div><div><br></div><div>Best,</div><div>Karl</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But especially now that the interest in themes came<br>
up again, the colors might be changed.<br>
<br>
IMHO the designation of the origin<br>
(local/remote/mine/ours/theirs/other) should be added to the buttons.<br>
The verb then becomes less important which is good, because apparently<br>
there are different perspectives on the operation. Also, the other<br>
tools mentioned above all name the options after their origin, so it<br>
may be easier for newcomers if Monticello did so as well. If we<br>
include a verb, my personal favourites would be "keep local" and<br>
"accept/use remote" (in that order, which would mean to swap the<br>
buttons, but I understand if that is rejected).<br>
<span class="im HOEnZb"><br>
2016-01-23 17:37 GMT+01:00 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
> Hi Fabio, Chris,<br>
><br>
> On Jan 22, 2016, at 4:00 PM, Fabio Niephaus <<a href="mailto:lists@fniephaus.com">lists@fniephaus.com</a>> wrote:<br>
><br>
</span><span class="im HOEnZb">> I think that it's not only the naming but also the direction that is<br>
> confusing. Sorry for being selfish, but I usually care about my own stuff<br>
> more than about the stuff on the server, right?<br>
><br>
> How about:<br>
><br>
> Keep -> 'Replace Local'<br>
> Reject -> 'Keep Local'<br>
><br>
><br>
</span><span class="im HOEnZb">> Let's try and search for more candidates. The two word ones are clunky and<br>
> long. Keep is horrible because it conflicts with the sense of "keep what's<br>
> mine". But some other duals are (where left is Replace Local and right is<br>
> Keep Local)<br>
><br>
> Import vs Exclude<br>
> Accept vs Reject<br>
> Merge vs Ignore<br>
> Advance vs Remain<br>
> Approve vs Disapprove<br>
><br>
> More of a stretch but may trigger thought:<br>
> Infect vs Quarantine<br>
> Ingest vs Refuse<br>
><br>
> and the question mark at the end of each suggestion is implicit ;-)<br>
><br>
> Any other suggestions?<br>
><br>
</span><div class="HOEnZb"><div class="h5">> This is also what most syncing services name the two options when you<br>
> start using them (e.g. iCloud or Google Chrome Sync).<br>
><br>
> Best,<br>
> Fabio<br>
><br>
> --<br>
><br>
> On Fri, Jan 22, 2016 at 11:41 PM Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com">cunningham.cb@gmail.com</a>><br>
> wrote:<br>
>><br>
>> So, once again, I am bitten by these button labels. They just don't speak<br>
>> to me.<br>
>><br>
>> From back in 2013, there was a description by Nice that explained it thus:<br>
>> "If you say keep, then you accept the incoming version to replace your<br>
>> version.<br>
>> If you say reject, then refuse the incoming version and prefer to keep<br>
>> your own version."<br>
>><br>
>> Then back in 2015, another discussion about what these values mean with<br>
>> several options thrown out. But it looks like we still have Keep and Reject<br>
>> - which still confuses me.<br>
>><br>
>> Maybe we could just relabel them the way Nice suggested:<br>
>> Keep -> 'Keep Incoming'<br>
>> Reject -> 'Reject Incoming'<br>
>> ? Maybe also update the balloon help to take Nice's exact words?<br>
>><br>
>> I'll push a change later tonight/tomorrow to the InBox unless I hear back<br>
>> that this is a horrible idea.<br>
>><br>
>> Thanks,<br>
>> cbc<br>
>><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>