- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

by Guillermo Polito

Hi, On Mon, Feb 4, 2019 at 6:19 PM Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > Currently in Iceberg to merge a branch into another, we need to checkout > the branch into which we want to merge and then do the merge. > For the moment it is done that way because - every commit is first written in disk before moved to the index and then commited - a merge, unless fast forward, will need to create a new commit, and potentially if there is a merge conflict it requires some manual intervention Also, we have decided for the moment to follow git's semantics to avoid MORE terminology/technological mismatch than what we have. We could implement the merge operation to work on any two arbitrary branches, but still in case of merge conflict it's not so straight forward. We have discussed in Esug with some guys, and there would be the possibility to have automatic merge strategies like: - take all incoming - take all outgoing But still there are cases where the user would like a mix of them, and even do manual modifications. Checking out a branch also updates the code in the image, which when > needing to perform automatic releases on a branch can cause issues. > > Is there already a way in Iceberg to switch to a branch (for example > `release`) and then merge another branch (for example `master`) into it > without updating any code in the image? > The use-case is that the user is on the `master` branch and needs to merge > `master` into `release` without changing any code in the image. > Yes, when you checkout a branch, there is a combobox: [image: image.png] You can choose the last option for it. These are called in iceberg CheckoutStrategies, and though they are so far only used for checkouts, they could be used for merge toos. > > I found LGitRepository>>#merge:, but it seems not to be used anywhere in > the image. > > Another way would be to implement something like the method below. This: > - calculates what changes need to be merged > - always takes what is on the left branch (in this case what is on > master overrides what is on release) > - does not call loadChangesInWorkingCopy: to update the working copy as > the code is already in the image > - refreshes the dirty packages in case there are changes between what is > on the image and what is on disk > > ``` > IceMerge>>#executeWithAcceptingLeftOnConflictAndWithoutImageUpdate > | commitToAdvance | > mergeCommit validateCanMerge. > self isAlreadyMerged ifTrue: [ ^ self ]. > > self calculateChanges. > self conflictsDo: [ :operation | > operation selectLeft. > ]. > commitToAdvance := self updateHead. > "Do not update the working copy" > "repository workingCopy loadChangesInWorkingCopy: self > changesToWorkingCopyTree." > repository workingCopy refreshDirtyPackages. > ^ commitToAdvance > ``` > > Could something like the above solution work? Or are there other issues to > take into account? > I think something like that would work... But it would be nice to extract those things to be more reusable? - a conflict resolution strategy (with a default "do not solve conflict") - a checkout strategy (with a checkout in image strategy). Anyway you go, I'd write some tests about that, since a broken merge can lead to super fuzzy behaviour (like losing code...) :) > Cheers, > Andrei > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 5, 2019

An article that talks about Pharo in a portal from MÃ©xico

by Esteban Lorenzano

https://www.unocero.com/smartphones/pharo-7-internet-de-las-cosas/ <https://www.unocero.com/smartphones/pharo-7-internet-de-las-cosas/> Just presenting version 7. Couple of observations: 1. We reach farther than we think. 2. IoT has a lot of attention at this moment. Esteban

Feb. 5, 2019

[Pharo 7.0] Build #147: Add scrollSelectionIntoView

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #147 was: SUCCESS. The Pull Request #2428 was integrated: "Add scrollSelectionIntoView" Pull request url: https://github.com/pharo-project/pharo/pull/2428 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 5, 2019

Re: [Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

by Ben Coman

On Tue, 5 Feb 2019 at 01:19, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > Currently in Iceberg to merge a branch into another, we need to checkout > the branch into which we want to merge and then do the merge. > Checking out a branch also updates the code in the image, which when > needing to perform automatic releases on a branch can cause issues. > > Is there already a way in Iceberg to switch to a branch (for example > `release`) and then merge another branch (for example `master`) into it > without updating any code in the image? > The use-case is that the user is on the `master` branch and needs to merge > `master` into `release` without changing any code in the image. > Another use case for this might be where I recently wanted to resurrect an old PR to contribute to Pharo 8 and loading the old code broke the image. I'd to update the PR by merging master into it without loading it. Rebasing the old PR onto master would be even better. Perhaps the existing <Merge> button becomes a <Merge & Load> button and the <Merge> button presents a dialog for any any-to-any disc-only merge (default would be "selected" commit into the image's "current" commit) cheers -ben

Feb. 5, 2019

Re: [Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?

by ducasse

Thomas I asked Gina to rewrite it in Spec (but it can be too complex because the code does not have a clear model) so if you want to help her, go ahead. Stef > On 4 Feb 2019, at 11:47, Thomas Dupriez <tdupriez(a)ens-paris-saclay.fr> wrote: > > Hello, > > The Process Browser does not auto-updates itself by default to show new processes and hide processes that stopped. > > Is there a specific reason for that? The first time I opened it I kind of expected it would auto-update itself, and I think this may be a more "intuitive" behaviour that no auto-updates by default. What do you think? > > Getting auto-updates is "easy" (there is no button in the UI (something to improve?), but one can call the "toggleAutoUpdate" method to get this behaviour). My question is about it not being default. > > Thomas > >

Feb. 5, 2019

Camp Smalltalk Charlotte 2019 Update!

by Mariano Martinez Peck

Hello Smalltalkers, Camp Smalltalk Charlotte 2019 is looking good! At this point we are over half full. Looks like some cool demos using different Smalltalk dialects are already lining up. A google groups forum has been created for attendees so everyone can collaborate beforehand. Attendees will get an invitation for group access shortly after registering. This event is happening March 29th â March 31st 2019 in Charlotte, North Carolina. Please register for the event as spots will be limited. Event details and registration info are available at the following link: Camp Smalltalk Charlotte 2019 <https://www.google.com/url?q=https%3A%2F%2Fwww.eventbrite.com%2Fe%2Fcamp-sm…> Hope to see you there! -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

Feb. 4, 2019

iceberg: merging branches just at the git level without changing code in the image

by Andrei Chis

Hi, Currently in Iceberg to merge a branch into another, we need to checkout the branch into which we want to merge and then do the merge. Checking out a branch also updates the code in the image, which when needing to perform automatic releases on a branch can cause issues. Is there already a way in Iceberg to switch to a branch (for example `release`) and then merge another branch (for example `master`) into it without updating any code in the image? The use-case is that the user is on the `master` branch and needs to merge `master` into `release` without changing any code in the image. I found LGitRepository>>#merge:, but it seems not to be used anywhere in the image. Another way would be to implement something like the method below. This: - calculates what changes need to be merged - always takes what is on the left branch (in this case what is on master overrides what is on release) - does not call loadChangesInWorkingCopy: to update the working copy as the code is already in the image - refreshes the dirty packages in case there are changes between what is on the image and what is on disk ``` IceMerge>>#executeWithAcceptingLeftOnConflictAndWithoutImageUpdate | commitToAdvance | mergeCommit validateCanMerge. self isAlreadyMerged ifTrue: [ ^ self ]. self calculateChanges. self conflictsDo: [ :operation | operation selectLeft. ]. commitToAdvance := self updateHead. "Do not update the working copy" "repository workingCopy loadChangesInWorkingCopy: self changesToWorkingCopyTree." repository workingCopy refreshDirtyPackages. ^ commitToAdvance ``` Could something like the above solution work? Or are there other issues to take into account? Cheers, Andrei

Feb. 4, 2019

Re: [Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?

by Alistair Grant

On Mon, 4 Feb 2019 at 11:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I believe the reason not to make auto updating the default, is because #updateProcessList is a bit heavy (it calls a GC, does an #allSubInstances, and it is a thread itself). Maybe that is no longer the case ? > > But adding a button to make auto updating easier to start would probably help. > > Maybe a button bar for more common actions (like terminate) ? > > > On 4 Feb 2019, at 11:47, Thomas Dupriez <tdupriez(a)ens-paris-saclay.fr> wrote: > > > > Hello, > > > > The Process Browser does not auto-updates itself by default to show new processes and hide processes that stopped. > > > > Is there a specific reason for that? The first time I opened it I kind of expected it would auto-update itself, and I think this may be a more "intuitive" behaviour that no auto-updates by default. What do you think? > > > > Getting auto-updates is "easy" (there is no button in the UI (something to improve?), but one can call the "toggleAutoUpdate" method to get this behaviour). My question is about it not being default. You can right click on a process and "Turn on auto-update", which is Ctrl-A (on linux). A button bar would be more friendly. Cheers, Alistair

Feb. 4, 2019

Re: [Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?

by Sven Van Caekenberghe

I believe the reason not to make auto updating the default, is because #updateProcessList is a bit heavy (it calls a GC, does an #allSubInstances, and it is a thread itself). Maybe that is no longer the case ? But adding a button to make auto updating easier to start would probably help. Maybe a button bar for more common actions (like terminate) ? > On 4 Feb 2019, at 11:47, Thomas Dupriez <tdupriez(a)ens-paris-saclay.fr> wrote: > > Hello, > > The Process Browser does not auto-updates itself by default to show new processes and hide processes that stopped. > > Is there a specific reason for that? The first time I opened it I kind of expected it would auto-update itself, and I think this may be a more "intuitive" behaviour that no auto-updates by default. What do you think? > > Getting auto-updates is "easy" (there is no button in the UI (something to improve?), but one can call the "toggleAutoUpdate" method to get this behaviour). My question is about it not being default. > > Thomas > >

Feb. 4, 2019

ProcessBrowser does not auto-update itself by default? Should it?

by Thomas Dupriez

Hello, The Process Browser does not auto-updates itself by default to show new processes and hide processes that stopped. Is there a specific reason for that? The first time I opened it I kind of expected it would auto-update itself, and I think this may be a more "intuitive" behaviour that no auto-updates by default. What do you think? Getting auto-updates is "easy" (there is no button in the UI (something to improve?), but one can call the "toggleAutoUpdate" method to get this behaviour). My question is about it not being default. Thomas

Feb. 4, 2019