Le 02/12/2014 17:00, Luc Fabresse a écrit :
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?
ConfigurationOfAltBrowser, ConfigurationOfSmaCC show how to load directly from a GitHub repository (or, in the case of SmaCC, load some versions from smalltalkhub, other from github, depending on the version you choose). But the best is the BaselineOf as explained by Dale, especially given that it can works with git tags (and github:// urls). gitfiletree:// urls are designed for development and to couple you with the github repository.
- 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?
Yes. Part of it has been automated via gitfiletree, but more should be done to automate. Still, it is reasonable to assume that you'll need access to git command line in real life, and integrating it as an embedded shell inside Smalltalk is a very nice way of handling it.
- Merging could be harder because it would rely on git tools?
Not really if you use the merge driver. For a large merge, git-based tools are a lot faster than Monticello, except for the merge driver which slows done the process a bit (it's written in Pharo, Pharo startup time is significant, and it is called often by git during a merge).
- 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
Yes, you should be ready to pull (or pull often). But pull does a merge, so you have to know what you're doing: conflicts may appear on a pull. In a well organized multi-developper project, you'll work on a personal branch and conflicts won't happen. But git is designed in such a way that a git user can easily shot himself in the foot and create conflicts for his co-workers. git rebase is a good example of how to do that.
Thx for enlightening me,
#Luc
You're welcome, Thierry