> On 02 Dec 2014, at 20:41, Yuriy Tymchuk <[email protected]> wrote: > >> >> On 02 Dec 2014, at 19:03, Thierry Goubier <[email protected]> wrote: >> >> Le 02/12/2014 17:13, Yuriy Tymchuk a écrit : >>> Hi Luc, >>> >>> most of these problems are solved by gitfiletree by Goubier Thierry. >>> It automatically commits the thing that you commit with Monticello, >>> it allows you to push, and it shows you the history (sometimes a bit >>> screwed, but good enough). ConfigurationOf works with GitHub >>> projects, but I think there is also something in a new Metacello that >>> I don’t know about. >> >> If you find a strange history, can you share? It seems it happens, but I'm >> never sure. It handles fairly complicated cases (like the FileTree >> repository where, in some commits, you can't load the packages with filetree >> because they are broken: merge conflicts usually). >> >>> Big con is that you essentially communicate with git through >>> Monticello. And to doing advanced stuff, like a lot of branching, >>> pull requests and so on, gives an impression that you are always >>> hacking something. >> >> I think this is the git philosophy anyway. You need to go on expensive, >> entreprise versionning systems (ClearCase?) to have a very powerfull, yet >> still handholding system. Git is a hacker's tool. And git users are supposed >> (encouraged?) to hack it. > > My problem is not in git, it’s in Monticello. I’m used to be able to commit > exactly what I want even if I’ve made more changes, I’m used to make branches > for each new feature and then merge it back… But I always have two versioning > going on. I do things in git, and then I do things in monticello. Another > problem is a real lack of features. Imagine if you could see a method blame > from inside Pharo. > >> >>> If you want to really work with git, you want to be able to have only >>> git versions of your code, stage and commit certain changes, >>> communicate with remote repos, and if something goes wrong talk to >>> command line and deal with file-based pharo representation. But >>> instead of this you have one more screen of Monticello + nasty >>> metadata which complicates merging. >> >> You need to use the merge driver for that, really. Ok, it requires a lot >> more polish than it has, but this is a larger, Pharo wide effort we need to >> plan for. The GitFileTree-MergeDriver was really a proof-of-concept which >> worked surprisingly well for the time I spent on it. > > Yes, but my main point is what when I merge, I don’t care about monticello > data… I already have a git version, why do I have to care about the ancestor > of monticello version that became different because of cherrypicking.
And this is what we need to fix. We do not need this duplications, and also it makes a lot more difficult to work in several branchs, etc. Esteban > > > Again, I’m not complaining. I’m very glad that we have what we have now. It’s > just that I don’t agree that git support is ready to be used by everyone. > Because with git in general I’m 10x more efficient than with git in Pharo. > And with git in pharo it’s the same as with monticello, I just trade one > problems for another ones. > > Uko > >> >> Thierry >> >>> Uko >>> >>>> On 02 Dec 2014, at 17:00, Luc Fabresse <[email protected]> >>>> wrote: >>>> >>>> Hi, >>>> >>>> I continue the discussion here because I really would like to know >>>> the cons of using Git + Pharo. From kilon's video (thx) and the >>>> discussion that followed, I have the following questions about >>>> possible drawbacks of Git+Pharo: >>>> >>>> - The most important point to me is: does ConfigurationOf work >>>> correctly with a repo on GitHub for example? any example >>>> somewhere? >>>> >>>> - we should go to command line to commit/update but that could be >>>> saved with what has been done by Dale in tODE (shell integration, >>>> UI to commit, push/pull) IIUC. right? >>>> >>>> - Merging could be harder because it would rely on git tools? >>>> >>>> - opening a filetree repo in MC does not show the latest content >>>> since it is the local git repo that may not be in sync with the >>>> remote one => you should first pull the repo >>>> >>>> Thx for enlightening me, >>>> >>>> #Luc
