Aaand, I've updated https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo
On Thu, May 24, 2018 at 11:34 AM, Guillermo Polito < guillermopol...@gmail.com> wrote: > https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies) > https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging > > On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito < > guillermopol...@gmail.com> wrote: > >> Hi, >> >> I'll take some minutes to provide an answer as detailed as possible to >> all questions in this mail, and to the ones in the mails before. >> But first, since I know most people only read the first lines of mails >> :P, if you find any concrete iceberg issues, please report them in >> >> https://github.com/pharo-vcs/iceberg/issues >> >> Now, answers inline. >> >> On Tue, May 22, 2018 at 5:15 PM, Tim Mackinnon <tim@testit.works> wrote: >> >>> Hi - last night we managed to explore the new contribution process as >>> well as the new iceberg ui at the U.K. Smalltalk meetup last night. >>> >> >> Cool! >> >> >>> >>> Not many had seen it before so it was a good test run. >>> >>> As an initial comment - we need to invest a small amount of time to get >>> the right docs in places you expect them as not doing so undoes a lot of >>> good work - the Pharo main site that points to old contribution docs (and >>> doesn’t reference the new ones) must be updated ASAP to keep energy high >>> (we almost lost a few folks last night by going down the wrong path - >>> fortunately Cyril piped up on Discord for me - phew). >>> >> >> I know. This is indeed important. I'm trying to get time to make videos, >> paste as much info in the wiki. Now, it would be good to know what was >> exactly your "wrong path". The more concrete you are, the easier is to fix >> it :). >> I see Pharo contribution page (http://pharo.org/contribute-propose-fix) >> points to https://github.com/pharo-project/pharo/wiki/Contribute-a- >> fix-to-Pharo which is outdated. I'll fix it ASAP. >> >> >>> >>> Armed with the right steps it was straightforward - much easier than the >>> older slices mechanism (that I never was comfortable with) - so HUGE thanks >>> for that everyone! >>> >>> As we worked through it, the more git seasoned folks were confused why >>> git status in a terminal wasn’t really showing the same info as iceberg >>> (I’ll put this in a separate thread to discuss, as it’s an interesting >>> thought which I’m sure has lively discussion). >>> >> >> Well, this is the discussion in the other thread. If you have read the >> glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary), >> you will notice that iceberg presents you with two working copies: >> - the image working copy >> - the disk working copy >> >> The disk working copy is what most people know when they use git. The >> directory where you have your repository, with the files you're modifying. >> >> The image working copy represent what is loaded in Pharo. It's important >> to differentiate them because if I send you an image (or you download it >> from somewhere) you have code loaded on it. This working copy allows us to >> track how and where you loaded that code from. That is useful if later on >> you want to contribute to that project in some way. >> >> Then there are other questions: >> >> !! Why do we still have a disk working copy? >> >> Well, this is not really necessary for iceberg to work. Iceberg could >> just write source code directly on git's BLOB, as Thierry mentioned in the >> other thread. >> The reason for this working copy to be there is just to try to be less >> alien. >> Having the disk working copy allows people to still have a way to: >> - edit non-smalltalk files from the command like >> - use the non command line as a last ressource if something goes wrong >> with your Pharo image >> - use external tools to manage the repository (sourcetree, git kraken, >> whatever you're confortable with) >> >> The idea is that Iceberg will try to keep your disk working copy in sync >> with your repository HEAD. >> It will take care of transparently synchronizing your disk working copy >> when: >> - you commit >> - you change branches >> - you pull/push/merge >> >> !! Why don't we dump code into the disk as we write it? >> >> The main reason behind it is that the image is not causally connected to >> the directory in disk, as Ben implied. >> There is not a 1 to 1 correspondence between what you could ever have in >> disk and your running image. >> As Ben mentionned, for this to happen: >> - changing the source code in disk should get automatically loaded into >> Pharo >> - changing the source code in Pharo should get automatically written in >> disk >> >> The thing is that this is much more difficult than it sounds: >> - What happens if you do not want to save your image, you forgot to save >> it or it crashes? Suddenly you will have an image that is not in sync with >> your repository. Would you load all changes into your image as soon as you >> reopen it? Atomically? >> - What happens if you share your repository between several images? >> - Or if suddenly you change your branch from the command line to >> something completely different? >> >> Several of these usecases don't even make sense. So we preferred to >> choose the path of "make it explicit". >> Of course, we could do better, we are open to discuss any improvements. >> Just take into account that Iceberg did not come from an egg :) we have >> thought about many possible scenarios and discussed with a lot of people >> before. >> >> !! How does merge work? >> >> First, just for the record, merge works. We even >> - detect fast forward merge avoiding the creation of extra merge commits >> - proposing a single UI to resolve all conflicts of a project at once >> and not one per package >> >> Now, as Thierry suggested in the other thread, Iceberg's merge happen in >> memory. The reason behind this is that using Git's default merge mechanism >> would insert the >>>> <<<< markers in the conflicting files. This would >> break our parsers and all our tools. >> Instead, we ask git for the list of conflicting files, and we build a >> diff tree in memory, that we later augment with information such as >> conflicts. >> >> There are some issues we have seen when merging external files, but as >> soon as the two merged commits are not merging external files, but we hope >> we will fix them soon. >> >> Missing feature: right now we can only choose between incoming or loaded >> version during a merge. It would be nice to be able to edit a method's >> code, picking part of the incoming code and part of the current code. >> >> Missing feature 2: right now we resolve all conflicts in memory and >> commit them at once. We know some people would like to, instead, not do the >> merge automatically, so they can test it before committing. This should not >> be tooo difficult to do but it was down in the priority list :). >> >> !! Exporting without commiting? >> >> There is no UI support for this, but it is doable from the backend, >> though not correctly exposed right now. >> >> You can right-click on the repository -> Extras -> Inspect >> >> repository index updateDiskWorkingCopy: repository workingCopy >> workingCopyDiff. >> >> >>> Anyway - the new UI does take some getting used to (personally I liked >>> the compactness of the original Iceberg and its tabs), but when you >>> understand what the different windows show you - I think it makes sense >>> (and hopefully is more stable). >> >> >> Well, the UI rewriting has several ideas behind. I'll put whichever ones >> come to my mind in here, I hope Esteban will correct me if I'm wrong: >> >> - Moving from Glamour to Spec. This is a purely technical decision. >> AFAIK, maybe I'm wrong, Glamour is not being maintained anymore by the GT >> team, and it has some rough corners that made the old UI difficult to deal >> with sometimes. From an investment of time standpoint, we decided to put >> effort in Spec instead... >> - Simplify the UI. We needed it to be less overwhelming and sometimes >> more direct. That's the why of the toolbar on the top, and the more (but >> smaller and simpler) windows. >> >> Regarding the design, Esteban followed some UI guidelines for the design >> taken from I don't where. But at the end we are engineers, not UI >> designers, so we make ugly UIs by default :P. >> Any improvement or concrete suggestion on this direction is welcome :). >> >> >>> We all missed having an obvious Diff mechanism - we later spotted that >>> Commit does show this (Although possibly calling it “Commit…” might make it >>> more obvious that you have a chance to review changes and change your mind) >>> - but knowing the size of your change and reviewing them without any danger >>> of committing something is a useful feature (but maybe a 2.0 enhancement >>> request?). >>> >> >> Yes, I want that also. I miss >> - a Diff/See Changes button. >> - that the tabs that show the diffs should maybe say "Diff: XXX to YYY" >> instead of just "XXX to YYY" >> >> Could you open an issue? >> >> >>> >>> One small tweak (which I would PR if I knew how to - would be to swap >>> the status and branch columns in the Repository window to make the status >>> clearer (the status gets lost as it sqashed against the normally much >>> longer branch name). Its a simple change to #initializeRepositoryList but >>> I guess Iceberg is in a different repository (and not in the instructions >>> for contirbutions). >>> >> >> Could you open an issue? >> >> >>> >>> We also noticed that if you try to use the “Create Pull Request” menu >>> item, you can’t if you have 2FA enabled on Github (the recommended setting) >>> as I guess that ssh protocol doesn’t allow this with an ssh key? So I we >>> should update the instructions to suggest either using the web ui - or - >>> creating an app specific login (that doesn’t use 2fa). - I’ll look at how >>> to add that tweak and send a PR. >>> >> >> Ouki :) >> >> Thanks! >> >> >>> >>> >>> Tim >>> >>> >>> Sent from my iPhone >>> >> >> >> >> -- >> >> >> >> 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 >> > > > > -- > > > > 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 > -- 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
