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

karl ramberg karlramberg at gmail.com
Sun Jan 24 12:34:13 UTC 2016


On Sun, Jan 24, 2016 at 1:21 PM, 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.


So we could have Blue pill and Red pill  ? :-)

Best,
Karl



> 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).
>
> 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
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160124/d12bdc35/attachment.htm


More information about the Squeak-dev mailing list