> On 03 Dec 2014, at 04:16, Eliot Miranda <[email protected]> wrote: > > > > On Tue, Dec 2, 2014 at 11:41 AM, Yuriy Tymchuk <[email protected] > <mailto:[email protected]>> wrote: > > > On 02 Dec 2014, at 19:03, Thierry Goubier <[email protected] > > <mailto:[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. > > So *implement* it. At least in Monticello *you* can make a change and have > it spread through the entire Squeak/Pharo community very quickly. You can't > do that with git. Your criticisms of git+Monticello don't hold up in pure > Monticello.
Yes, true, but Monticello can be missing versions, and I don’t want to work with not reliable data. > > > > > >> 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. > > Yes, but *I* care about the Monticello metadata. IMO its *better* than the > git metadata. What's really lacking in Monticello is a) it's not high school > so one can't preen in front of the world on github and b) it has no support > for external files. Well, a) will be solved by growing up and b) can be > solved by building the solution. I know what I'd rather do. For me one of the worst problems is that Monticello remains the bag of zips. I can throw away some zips and it will not complain. What kind of history is that? Oh yes, there are no branches, which again can be implemented, but I’d rather use something maintained by other people. Uko > > > [and apologies for being deliberately incendiary but I *hate* the movement > away from tools in Squeak/Pharo. It is a movement towards stasis and death, > and personally I'm enjoying life too much]. > > > > 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] > >>> <mailto:[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 > >> > >> > >> > > > > > > > > > > -- > best, > Eliot
