Merge tool. No way to cherry pick the changes?

> I don't understand, when i merging, the merge tool showing me all the
> difference between current version and
> incoming one.
> It says '0 conflicts' and its ok to merge, but what if i want to
> choose to keep an old version for some methods, while merge the rest?
>
> What i see that there is no way to do that .. all menu items which
> would allow me to do that, like
> 'keep current version'
> 'use incoming verison'
> 'mark as conflict'
> are disabled.
>
> Which means that once machine decided that there is no conflict, you
> cannot do much.
> I tried to quickly hack the UI and enable those menu items , but it
> doesn't works, because the model itself seems like don't supports
> that.
>
> So, the question is how we can change that? As to me, it is certainly
> a missing feature, if i cannot freely choose between current and
> incoming version at
> my will, when merging.
>
> Gary (& all)? Any ideas?
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Yeap, preety annoying.  It's annoying too that you can't do any kind of filter (for example, to not show the ones marked as "revision changed").  Merging Glorp was kind of a mess :).
>
> On Tue, Jun 21, 2011 at 11:00 AM, Adrian Lienhard <[hidden email]> wrote:
> I'm missing that too.
>
> In previous versions, IIRC, there was a menu item for changed methods named "Install".
>
> Adrian
>
> On Jun 21, 2011, at 14:37 , Igor Stasenko wrote:
>
> > I don't understand, when i merging, the merge tool showing me all the
> > difference between current version and
> > incoming one.
> > It says '0 conflicts' and its ok to merge, but what if i want to
> > choose to keep an old version for some methods, while merge the rest?
> >
> > What i see that there is no way to do that .. all menu items which
> > would allow me to do that, like
> > 'keep current version'
> > 'use incoming verison'
> > 'mark as conflict'
> > are disabled.
> >
> > Which means that once machine decided that there is no conflict, you
> > cannot do much.
> > I tried to quickly hack the UI and enable those menu items , but it
> > doesn't works, because the model itself seems like don't supports
> > that.
> >
> > So, the question is how we can change that? As to me, it is certainly
> > a missing feature, if i cannot freely choose between current and
> > incoming version at
> > my will, when merging.
> >
> > Gary (& all)? Any ideas?
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
>
>
>

>I don't understand, when i merging, the merge tool showing me all the
> difference between current version and
> incoming one.
> It says '0 conflicts' and its ok to merge, but what if i want to
> choose to keep an old version for some methods, while merge the rest?
>
> What i see that there is no way to do that .. all menu items which
> would allow me to do that, like
> 'keep current version'
> 'use incoming verison'
> 'mark as conflict'
> are disabled.
>
> Which means that once machine decided that there is no conflict, you
> cannot do much.
> I tried to quickly hack the UI and enable those menu items , but it
> doesn't works, because the model itself seems like don't supports
> that.
>
> So, the question is how we can change that? As to me, it is certainly
> a missing feature, if i cannot freely choose between current and
> incoming version at
> my will, when merging.
>
> Gary (& all)? Any ideas?
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Here the code
> http://code.google.com/p/pharo/issues/detail?id=4439
>
> please tell me if it works for you.
> I tested on simple merge and it works fine (the changes which i marked
> as not applicable are not loaded).
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> No need for the extra menu item then.
>
> Regards, Gary
>
> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
> To: <[hidden email]>
> Sent: Wednesday, June 22, 2011 3:40 PM
> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>
>
>> Here the code
>> http://code.google.com/p/pharo/issues/detail?id=4439
>>
>> please tell me if it works for you.
>> I tested on simple merge and it works fine (the changes which i marked
>> as not applicable are not loaded).
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>

>
> Because strangely , instead of using field to indicate a conflict (in
> MCPatchOperation record) it does something strange and overly
> complicated
> (MCConflict).
>
> So, then each entry could contain
> 'isApplicable'
> and
> 'isConflicting'
>
> and once user resolves the conflict, the isConflicting should be set to false,
> while isApplicable are uniformly to indicate which version to use
> (current or incoming one), when merging.
>
>
>> No need for the extra menu item then.
>>
>> Regards, Gary
>>
>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Wednesday, June 22, 2011 3:40 PM
>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>>
>>
>>> Here the code
>>> http://code.google.com/p/pharo/issues/detail?id=4439
>>>
>>> please tell me if it works for you.
>>> I tested on simple merge and it works fine (the changes which i marked
>>> as not applicable are not loaded).
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

>> Because strangely , instead of using field to indicate a conflict (in
>> MCPatchOperation record) it does something strange and overly
>> complicated
>> (MCConflict).
>>
>> So, then each entry could contain
>> 'isApplicable'
>> and
>> 'isConflicting'
>>
>> and once user resolves the conflict, the isConflicting should be set to false,
>> while isApplicable are uniformly to indicate which version to use
>> (current or incoming one), when merging.
>>
>>
>>> No need for the extra menu item then.
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Wednesday, June 22, 2011 3:40 PM
>>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>>>
>>>
>>>> Here the code
>>>> http://code.google.com/p/pharo/issues/detail?id=4439
>>>>
>>>> please tell me if it works for you.
>>>> I tested on simple merge and it works fine (the changes which i marked
>>>> as not applicable are not loaded).
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

>>>> Perhaps the "non-applicable" could be streamlined.
>>>> I.e., "keep current version" = not applicable.
>>>>
>>> yes, could be..
>>> but that logic are only for conflics.. and i didn't wanted to mess
>>> with it because its a lot more work.
>>
>> btw, Stephane, this is a good topic for dealing with it on friday, if
>> you don't have anything else in mind.
>
> ok
> did you run MC tests?
> I htink that we should invest more in running tests.
>

>
>
>>> Because strangely , instead of using field to indicate a conflict (in
>>> MCPatchOperation record) it does something strange and overly
>>> complicated
>>> (MCConflict).
>>>
>>> So, then each entry could contain
>>> 'isApplicable'
>>> and
>>> 'isConflicting'
>>>
>>> and once user resolves the conflict, the isConflicting should be set to false,
>>> while isApplicable are uniformly to indicate which version to use
>>> (current or incoming one), when merging.
>>>
>>>
>>>> No need for the extra menu item then.
>>>>
>>>> Regards, Gary
>>>>
>>>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>>>> To: <[hidden email]>
>>>> Sent: Wednesday, June 22, 2011 3:40 PM
>>>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>>>>
>>>>
>>>>> Here the code
>>>>> http://code.google.com/p/pharo/issues/detail?id=4439
>>>>>
>>>>> please tell me if it works for you.
>>>>> I tested on simple merge and it works fine (the changes which i marked
>>>>> as not applicable are not loaded).
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>

> On 22 June 2011 23:10, Stéphane Ducasse <[hidden email]> wrote:
>>>>> Perhaps the "non-applicable" could be streamlined.
>>>>> I.e., "keep current version" = not applicable.
>>>>>
>>>> yes, could be..
>>>> but that logic are only for conflics.. and i didn't wanted to mess
>>>> with it because its a lot more work.
>>>
>>> btw, Stephane, this is a good topic for dealing with it on friday, if
>>> you don't have anything else in mind.
>>
>> ok
>> did you run MC tests?
>> I htink that we should invest more in running tests.
>>
>
> well, the changes i made are not intrusive, i mean it will work as before
> unless user plays with this flag using UI.
> So, MC will behave exactly as before and there is no problem from that side.
>
>>
>>
>>>> Because strangely , instead of using field to indicate a conflict (in
>>>> MCPatchOperation record) it does something strange and overly
>>>> complicated
>>>> (MCConflict).
>>>>
>>>> So, then each entry could contain
>>>> 'isApplicable'
>>>> and
>>>> 'isConflicting'
>>>>
>>>> and once user resolves the conflict, the isConflicting should be set to false,
>>>> while isApplicable are uniformly to indicate which version to use
>>>> (current or incoming one), when merging.
>>>>
>>>>
>>>>> No need for the extra menu item then.
>>>>>
>>>>> Regards, Gary
>>>>>
>>>>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>>>>> To: <[hidden email]>
>>>>> Sent: Wednesday, June 22, 2011 3:40 PM
>>>>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>>>>>
>>>>>
>>>>>> Here the code
>>>>>> http://code.google.com/p/pharo/issues/detail?id=4439
>>>>>>
>>>>>> please tell me if it works for you.
>>>>>> I tested on simple merge and it works fine (the changes which i marked
>>>>>> as not applicable are not loaded).
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Igor Stasenko AKA sig.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

> Isn't it one of the features supported by backport ?
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094.html
>
> Nicolas
>
> 2011/6/23 Igor Stasenko <[hidden email]>:
>> On 22 June 2011 23:10, Stéphane Ducasse <[hidden email]> wrote:
>>>>>> Perhaps the "non-applicable" could be streamlined.
>>>>>> I.e., "keep current version" = not applicable.
>>>>>>
>>>>> yes, could be..
>>>>> but that logic are only for conflics.. and i didn't wanted to mess
>>>>> with it because its a lot more work.
>>>>
>>>> btw, Stephane, this is a good topic for dealing with it on friday, if
>>>> you don't have anything else in mind.
>>>
>>> ok
>>> did you run MC tests?
>>> I htink that we should invest more in running tests.
>>>
>>
>> well, the changes i made are not intrusive, i mean it will work as before
>> unless user plays with this flag using UI.
>> So, MC will behave exactly as before and there is no problem from that side.
>>
>>>
>>>
>>>>> Because strangely , instead of using field to indicate a conflict (in
>>>>> MCPatchOperation record) it does something strange and overly
>>>>> complicated
>>>>> (MCConflict).
>>>>>
>>>>> So, then each entry could contain
>>>>> 'isApplicable'
>>>>> and
>>>>> 'isConflicting'
>>>>>
>>>>> and once user resolves the conflict, the isConflicting should be set to false,
>>>>> while isApplicable are uniformly to indicate which version to use
>>>>> (current or incoming one), when merging.
>>>>>
>>>>>
>>>>>> No need for the extra menu item then.
>>>>>>
>>>>>> Regards, Gary
>>>>>>
>>>>>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>>>>>> To: <[hidden email]>
>>>>>> Sent: Wednesday, June 22, 2011 3:40 PM
>>>>>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>>>>>>
>>>>>>
>>>>>>> Here the code
>>>>>>> http://code.google.com/p/pharo/issues/detail?id=4439
>>>>>>>
>>>>>>> please tell me if it works for you.
>>>>>>> I tested on simple merge and it works fine (the changes which i marked
>>>>>>> as not applicable are not loaded).
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Igor Stasenko AKA sig.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>

> Nicolas
>
> 2011/6/23 Igor Stasenko <[hidden email]>:
>> On 22 June 2011 23:10, Stéphane Ducasse <[hidden email]> wrote:
>>>>>> Perhaps the "non-applicable" could be streamlined.
>>>>>> I.e., "keep current version" = not applicable.
>>>>>>
>>>>> yes, could be..
>>>>> but that logic are only for conflics.. and i didn't wanted to mess
>>>>> with it because its a lot more work.
>>>>
>>>> btw, Stephane, this is a good topic for dealing with it on friday, if
>>>> you don't have anything else in mind.
>>>
>>> ok
>>> did you run MC tests?
>>> I htink that we should invest more in running tests.
>>>
>>
>> well, the changes i made are not intrusive, i mean it will work as before
>> unless user plays with this flag using UI.
>> So, MC will behave exactly as before and there is no problem from that side.
>>
>>>
>>>
>>>>> Because strangely , instead of using field to indicate a conflict (in
>>>>> MCPatchOperation record) it does something strange and overly
>>>>> complicated
>>>>> (MCConflict).
>>>>>
>>>>> So, then each entry could contain
>>>>> 'isApplicable'
>>>>> and
>>>>> 'isConflicting'
>>>>>
>>>>> and once user resolves the conflict, the isConflicting should be set to false,
>>>>> while isApplicable are uniformly to indicate which version to use
>>>>> (current or incoming one), when merging.
>>>>>
>>>>>
>>>>>> No need for the extra menu item then.
>>>>>>
>>>>>> Regards, Gary
>>>>>>
>>>>>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>>>>>> To: <[hidden email]>
>>>>>> Sent: Wednesday, June 22, 2011 3:40 PM
>>>>>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>>>>>>
>>>>>>
>>>>>>> Here the code
>>>>>>> http://code.google.com/p/pharo/issues/detail?id=4439
>>>>>>>
>>>>>>> please tell me if it works for you.
>>>>>>> I tested on simple merge and it works fine (the changes which i marked
>>>>>>> as not applicable are not loaded).
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Igor Stasenko AKA sig.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>

> On 25 June 2011 22:18, Nicolas Cellier
> <[hidden email]> wrote:
>> Isn't it one of the features supported by backport ?
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094.html
>>
>
> yes, sounds similar.
> Except that i never used this feature since it is mystery to me, how it works.
> Documentation....

>
>> Nicolas
>>
>> 2011/6/23 Igor Stasenko <[hidden email]>:
>>> On 22 June 2011 23:10, Stéphane Ducasse <[hidden email]> wrote:
>>>>>>> Perhaps the "non-applicable" could be streamlined.
>>>>>>> I.e., "keep current version" = not applicable.
>>>>>>>
>>>>>> yes, could be..
>>>>>> but that logic are only for conflics.. and i didn't wanted to mess
>>>>>> with it because its a lot more work.
>>>>>
>>>>> btw, Stephane, this is a good topic for dealing with it on friday, if
>>>>> you don't have anything else in mind.
>>>>
>>>> ok
>>>> did you run MC tests?
>>>> I htink that we should invest more in running tests.
>>>>
>>>
>>> well, the changes i made are not intrusive, i mean it will work as before
>>> unless user plays with this flag using UI.
>>> So, MC will behave exactly as before and there is no problem from that side.
>>>
>>>>
>>>>
>>>>>> Because strangely , instead of using field to indicate a conflict (in
>>>>>> MCPatchOperation record) it does something strange and overly
>>>>>> complicated
>>>>>> (MCConflict).
>>>>>>
>>>>>> So, then each entry could contain
>>>>>> 'isApplicable'
>>>>>> and
>>>>>> 'isConflicting'
>>>>>>
>>>>>> and once user resolves the conflict, the isConflicting should be set to false,
>>>>>> while isApplicable are uniformly to indicate which version to use
>>>>>> (current or incoming one), when merging.
>>>>>>
>>>>>>
>>>>>>> No need for the extra menu item then.
>>>>>>>
>>>>>>> Regards, Gary
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>>>>>>> To: <[hidden email]>
>>>>>>> Sent: Wednesday, June 22, 2011 3:40 PM
>>>>>>> Subject: Re: [Pharo-project] Merge tool. No way to cherry pick the changes?
>>>>>>>
>>>>>>>
>>>>>>>> Here the code
>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=4439
>>>>>>>>
>>>>>>>> please tell me if it works for you.
>>>>>>>> I tested on simple merge and it works fine (the changes which i marked
>>>>>>>> as not applicable are not loaded).
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>> Igor Stasenko AKA sig.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Igor Stasenko AKA sig.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

>
> On Jun 27, 2011, at 1:26 PM, Igor Stasenko wrote:
>
>> On 25 June 2011 22:18, Nicolas Cellier
>> <[hidden email]> wrote:
>>> Isn't it one of the features supported by backport ?
>>>
>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094.html
>>>
>>
>> yes, sounds similar.
>> Except that i never used this feature since it is mystery to me, how it works.
>> Documentation....
>
> it is explained in the monticello chapter of pharo by example 2
>

>>
>>
>>> On 25 June 2011 22:18, Nicolas Cellier
>>> <[hidden email]> wrote:
>>>> Isn't it one of the features supported by backport ?
>>>>
>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/082094.html
>>>>
>>>
>>> yes, sounds similar.
>>> Except that i never used this feature since it is mystery to me, how it works.
>>> Documentation....
>>
>> it is explained in the monticello chapter of pharo by example 2
>>
>
> so, why you saying it's completely different?
> one or another way, backport allows to cherry-pick changes (from what
> i have read in link that Nicolas gave).