Smalltalk › Squeak › Squeak - Dev

Monticello merge - what does Keep/Reject mean again?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

cbc

Monticello merge - what does Keep/Reject mean again?

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

fniephaus

Re: Monticello merge - what does Keep/Reject mean again?

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'

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 <[hidden email]> 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

David T. Lewis

Re: Monticello merge - what does Keep/Reject mean again?

+1 for Fabio's wording. "Replace/Keep Local" is easy for me to understand.

+1000 to Chris for fixing this. I cannot understand the current labels at all. Thank you!

Dave

On Sat, Jan 23, 2016 at 12:00:56AM +0000, Fabio Niephaus 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'
>
> 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 <[hidden email]>
> 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
> >
> >

Eliot Miranda-2

Re: Monticello merge - what does Keep/Reject mean again?

In reply to this post by fniephaus

Hi Fabio, Chris,

On Jan 22, 2016, at 4:00 PM, Fabio Niephaus <[hidden email]> 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 <[hidden email]> 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

Herbert König

Re: Monticello merge - what does Keep/Reject mean again?

Hi,

to me Fabios suggestion makes clear what the buttons do (I took a note because I never knew).
Clearer than the other suggestions. I like it _very_ clear.

Cheers,

Herbert

Am 23.01.2016 um 17:37 schrieb Eliot Miranda:

Hi Fabio, Chris,

On Jan 22, 2016, at 4:00 PM, Fabio Niephaus <[hidden email]> 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 <[hidden email]> 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

Levente Uzonyi

Re: Monticello merge - what does Keep/Reject mean again?

In reply to this post by cbc

It's easy to find out what they do, when you think like you're deciding
about changes, which is actually what you're doing.
You either Keep the selected change or Reject it.

Levente

On Fri, 22 Jan 2016, Chris Cunningham 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
>
>

Jakob Reschke-2

Re: Monticello merge - what does Keep/Reject mean again?

In reply to this post by fniephaus

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 <[hidden email]>:

> Hi Fabio, Chris,
>
> On Jan 22, 2016, at 4:00 PM, Fabio Niephaus <[hidden email]> 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 <[hidden email]>
> 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
>>
>

Karl Ramberg

Re: Monticello merge - what does Keep/Reject mean again?

On Sun, Jan 24, 2016 at 1:21 PM, Jakob Reschke <[hidden email]> 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 <[hidden email]>:
> Hi Fabio, Chris,
>
> On Jan 22, 2016, at 4:00 PM, Fabio Niephaus <[hidden email]> 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 <[hidden email]>
> 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
>>
>

Bert Freudenberg

Re: Monticello merge - what does Keep/Reject mean again?

In reply to this post by Eliot Miranda-2

On 23.01.2016, at 17:37, Eliot Miranda <[hidden email]> wrote:
>
> Any other suggestions?

“Keep mine” / “Accept incoming”

… or shorter:

“Mine” / “Incoming"

… and make the balloon help a little longer
“Keep the version in the image, rejecting the incoming change”
“Accept the incoming change, replacing the version in my image”

- Bert -

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: Monticello merge - what does Keep/Reject mean again?

> On Jan 24, 2016, at 6:31 AM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 23.01.2016, at 17:37, Eliot Miranda <[hidden email]> wrote:
>>
>> Any other suggestions?
>
> “Keep mine” / “Accept incoming”
>
> … or shorter:
>
> “Mine” / “Incoming"

+1. The two word ones are too long for button labels.

But I much prefer "Mine" and "Theirs" because they're both short, both a pair, both intuitive and both common to another dvcs.

>
> … and make the balloon help a little longer
> “Keep the version in the image, rejecting the incoming change”
> “Accept the incoming change, replacing the version in my image”
>
> - Bert -
>
>
>

Eliot Miranda-2

Re: Monticello merge - what does Keep/Reject mean again?

In reply to this post by Jakob Reschke-2

> On Jan 24, 2016, at 4:21 AM, Jakob Reschke <[hidden email]> 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 <[hidden email]>:
>> Hi Fabio, Chris,
>>
>> On Jan 22, 2016, at 4:00 PM, Fabio Niephaus <[hidden email]> 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 <[hidden email]>
>> 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
>

vaidasd

Re: Monticello merge - what does Keep/Reject mean again?

Hello,
let's change labels from 'old: ' to 'existing: ', and 'new: ' to 'pending: '.

Vaidotas

Eliot Miranda-2

Re: Monticello merge - what does Keep/Reject mean again?

On Sun, Jan 24, 2016 at 10:06 AM, Vaidotas Didžbalis <[hidden email]> 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

cbc

Re: Monticello merge - what does Keep/Reject mean again?

On Sun, Jan 24, 2016 at 10:41 AM, Eliot Miranda <[hidden email]> wrote:

On Sun, Jan 24, 2016 at 10:06 AM, Vaidotas Didžbalis <[hidden email]> 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

cbc

Re: Monticello merge - what does Keep/Reject mean again?

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 <[hidden email]> wrote:

On Sun, Jan 24, 2016 at 10:41 AM, Eliot Miranda <[hidden email]> wrote:

On Sun, Jan 24, 2016 at 10:06 AM, Vaidotas Didžbalis <[hidden email]> 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

cbc

Re: Monticello merge - what does Keep/Reject mean again?

On Sun, Jan 24, 2016 at 11:34 AM, Chris Cunningham <[hidden email]> 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

Chris Muller-3

Re: Monticello merge - what does Keep/Reject mean again?

In reply to this post by Eliot Miranda-2

> Let's try and search for more candidates. The two word ones are clunky

+1.

We want to balance a clean UI with one that is clear and obvious what
it does. What about the balloon help for those?

I feel the balloon help is very good UI feature to let the user "drill
deeper" into the UI widgets to understand what they do, without
intruding too much into the UI once the buttons are learned.

I think we should keep utilizing this capability of the IDE to
preserve the single-word elegance of whist expanding with any
necessary clarity in the balloons.

Presently, those balloon hints say, "Keep the selected change" and
"Reject the selected change." If we need to choose new button labels,
we should do it together with these balloon helps.

timrowledge

Re: Monticello merge - what does Keep/Reject mean again?

In reply to this post by Eliot Miranda-2

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: NBR: Unconditional No BRanch

marcel.taeumel

Re: Monticello merge - what does Keep/Reject mean again?

"Accept" and "Reject"?

Best,
Marcel

Robert Hirschfeld

Re: Monticello merge - what does Keep/Reject mean again?

(make it so)

> On 05 Feb 2016, at 13:53, marcel.taeumel <[hidden email]> wrote:
>
> "Accept" and "Reject"?
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Monticello-merge-what-does-Keep-Reject-mean-again-tp4873474p4876042.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>