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).
2016-01-23 17:37 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Fabio, Chris,
On Jan 22, 2016, at 4:00 PM, Fabio Niephaus lists@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@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
On Sun, Jan 24, 2016 at 1:21 PM, Jakob Reschke <jakob.reschke@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@gmail.com:
Hi Fabio, Chris,
On Jan 22, 2016, at 4:00 PM, Fabio Niephaus lists@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@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
On Jan 24, 2016, at 4:21 AM, Jakob Reschke jakob.reschke@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@gmail.com:
Hi Fabio, Chris,
On Jan 22, 2016, at 4:00 PM, Fabio Niephaus lists@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@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
Hello, let's change labels from 'old: ' to 'existing: ', and 'new: ' to 'pending: '. Vaidotas
On Sun, Jan 24, 2016 at 10:06 AM, Vaidotas Didžbalis vaidasd@gmail.com wrote:
Hello, let's change labels from 'old: ' to 'existing: ', and 'new: ' to 'pending: '.
+1. 'current' is a little shorter than 'existing', 'extant' shorter still, but a little unusual. But I love 'pending' because it doesn't presuppose age, and sometimes one is merging something older than the existing change.
Vaidotas
_,,,^..^,,,_ best, Eliot
On Sun, Jan 24, 2016 at 10:41 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sun, Jan 24, 2016 at 10:06 AM, Vaidotas Didžbalis vaidasd@gmail.com wrote:
Hello, let's change labels from 'old: ' to 'existing: ', and 'new: ' to 'pending: '.
+1. 'current' is a little shorter than 'existing', 'extant' shorter still, but a little unusual. But I love 'pending' because it doesn't presuppose age, and sometimes one is merging something older than the existing change.
'current' I like (mine is better - unless it isn't - it's just what was there). 'pending' is ok - but I would forget what it means in about a year. 'incoming' is less forgettable. And the baloon help definitely needs to be updated.
I'm not signing up yet (until I figure out how hard it is), but I would also love to have the two button color-coded to show which code in the diff pane relates to which button. Same with the author initials/dates. That would help significantly in reducing the confusion as well. Not mention let us change the colors - and I right that the red code is the proposed new code, and the blue crossed out code is the code going away? Why those colors? But that I'll leave for others to debate - if there is any desire. -chris
Vaidotas
_,,,^..^,,,_ best, Eliot
Ok, starting to look at the code. Should these name changes also apply to the top level buttons, currectly called 'Rest Local' and 'Rest Remote'? Or, should the bottom buttons reflect that word choice - Local and Remote?
One argument against it is that I usually work off of a local directory - so both are 'local' - but that is an easy fix for my thinking.
-cbc
On Sun, Jan 24, 2016 at 11:31 AM, Chris Cunningham cunningham.cb@gmail.com wrote:
On Sun, Jan 24, 2016 at 10:41 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sun, Jan 24, 2016 at 10:06 AM, Vaidotas Didžbalis vaidasd@gmail.com wrote:
Hello, let's change labels from 'old: ' to 'existing: ', and 'new: ' to 'pending: '.
+1. 'current' is a little shorter than 'existing', 'extant' shorter still, but a little unusual. But I love 'pending' because it doesn't presuppose age, and sometimes one is merging something older than the existing change.
'current' I like (mine is better - unless it isn't - it's just what was there). 'pending' is ok - but I would forget what it means in about a year. 'incoming' is less forgettable. And the baloon help definitely needs to be updated.
I'm not signing up yet (until I figure out how hard it is), but I would also love to have the two button color-coded to show which code in the diff pane relates to which button. Same with the author initials/dates. That would help significantly in reducing the confusion as well. Not mention let us change the colors - and I right that the red code is the proposed new code, and the blue crossed out code is the code going away? Why those colors? But that I'll leave for others to debate - if there is any desire. -chris
Vaidotas
_,,,^..^,,,_ best, Eliot
On Sun, Jan 24, 2016 at 11:34 AM, Chris Cunningham cunningham.cb@gmail.com wrote:
Ok, starting to look at the code. Should these name changes also apply to the top level buttons, currectly called 'Rest Local' and 'Rest Remote'? Or, should the bottom buttons reflect that word choice - Local and Remote?
For that matter, ALL of the code is written around Remote and Local.
Every bit of it - just several of the buttons and baloon help does not talk about Remote and Local.
If we want to go to Current and Incoming, then we should probably update the code to match, right?
-cbc
There’s an alternative way of handling this kind of issue and we even have a tool that sort of does it. Consider the Dual change sorter where one can move changes from one changeset to another by class, or by individual method and possibly other ways I don’t recall.
Perhaps the list of conflicts in a merge could be better displayed with a list of conflicts on the left, an originally empty list on the right and buttons/drag/menu options to move them to the ‘accept into my life’ list on the right. This would provide a very clear indication of what is going to be loaded, with plenty of time to change one’s mind if needed. I used something like this in the VMMakerTool for similar reasons.
I’d also like to urge some thought about what to do with methods where one already has a change but wants some of the incoming change too; an option to edit & add-to-load would be nice. Perhaps something relatively simple like adding the chosen method to a method browser just for those cases, with a nice label saying ‘deal with in a moment’?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: NBR: Unconditional No BRanch
"Accept" and "Reject"?
Best, Marcel
-- View this message in context: http://forum.world.st/Monticello-merge-what-does-Keep-Reject-mean-again-tp48... Sent from the Squeak - Dev mailing list archive at Nabble.com.
(make it so)
On 05 Feb 2016, at 13:53, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
"Accept" and "Reject"?
Best, Marcel
-- View this message in context: http://forum.world.st/Monticello-merge-what-does-Keep-Reject-mean-again-tp48... Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org
-
Chris Cunningham -
Eliot Miranda -
Jakob Reschke -
karl ramberg -
marcel.taeumel -
Robert Hirschfeld -
tim Rowledge -
Vaidotas Didžbalis