Le 29 nov. 2015 � 20:00, Dimitris Chloupis a �crit :
And there lies the trap.
If you end up making something that works with
everything, you will create something that just works
with everything instead of something that works very
well with one thing.
could be. But we do not want to plug everything. Just
having the door opened for the next cool VCS.
Even if is only used for git it is good to have a Pharo
API that is not the GIT API. We do not want git calls mixed
everywhere. We want a clean and clear API for versioning.
This API also prevents you from git API changes. You will
only have one place to update and so on.
Right now Git is by very far the undisputed king of
version control and has completely dethroned SVN.
King because widely used but other are also as valuable
if not more.
Ironically the things that make git integration in
pharo so hard is all the thing that are there to
decouple it from git , like filetree metadata , or
continuous support for mcz and monticello.�
I do not agree on this point.�There is no VCS
interoperability layer in Pharo. Tools are directly
manipulating Monticello.
In the end you cant have your cake and eat it too. We
will have to choose between very good integration with
git or average / mediocre integration with multiple
backends.�
again, I �cannot agree. It is a bad idea to have calls to
an external tool / library wide spread in the image. We need
our own API. It is particularly true for git that has an API
mixing daily tasks with other power admin commands (rewrite
of the history with possible code loss).
I do not think we need full support of git in the image,
i.e. supporting all commands and options, but only what is
needed to do correct versioning from Pharo (special git
commands can still be done with command-line).