Discussion:
Having a look at Git+Pharo
(too old to reply)
Damien Cassou
2015-09-09 14:04:09 UTC
Permalink
Hi,

today I wanted to have a look at how git integrates with Pharo. This is
what I found (mostly done by Thierry Goubier, thank you very much) and
what I didn't find:

- there is some documentation here:
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
But this is largely unfinished material. I contributed by adding a few
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress). Missing
things include:

- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)

- a discussion about moving a smalltalkhub repository to git while
preserving history

- a discussion on how to write Metacello configurations for a project
on git and for a project which depends on a project on git.

- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems
to work fine. I sent 3 minor pull requests.

- a list of tools missing before everyone uses git. For example:

- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Damien Cassou
2015-09-09 14:29:30 UTC
Permalink
something else I forgot:

- what happens if a Metacello description loads a project hosted in git
but I still want to be able to hack on this dependency. So, this
dependency should not be read-only for me

- where to put the git repositories when images are frequently deleted
and downloaded again from the launcher? What if I Pillar is hosted on
github, Jenkins build Pillar images, and I want to download an image
with Pillar inside? How do I link the Pillar of the image to a
repository? Which repository?
--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Thierry Goubier
2015-09-09 14:35:51 UTC
Permalink
Post by Damien Cassou
- what happens if a Metacello description loads a project hosted in git
but I still want to be able to hack on this dependency. So, this
dependency should not be read-only for me
Can you give an example?
Post by Damien Cassou
- where to put the git repositories when images are frequently deleted
and downloaded again from the launcher? What if I Pillar is hosted on
github, Jenkins build Pillar images, and I want to download an image
with Pillar inside? How do I link the Pillar of the image to a
repository? Which repository?
Having a gitfiletree repository with an auto-clone / lazy clone option
would work. When you open the repository for the first time, it clones it
from where it was originally referenced. May not work transparently if
there are authentification issues for the clone.

Thierry
Post by Damien Cassou
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Damien Cassou
2015-09-11 04:56:43 UTC
Permalink
Post by Thierry Goubier
Post by Damien Cassou
- what happens if a Metacello description loads a project hosted in git
but I still want to be able to hack on this dependency. So, this
dependency should not be read-only for me
Can you give an example?
For example, Cocoon is a framework to facilitate handling of user
configuration files. We created Cocoon by extracting code from Pillar
and Pillar is still the only user of Cocoon. This means we evolve Pillar
and Cocoon in parallel. The configuration of Pillar requires Cocoon. As
far as I understand, there are 2-ways to describe this dependency if
Cocoon is hosted on github:

1. Pillar depends on a read-only version of the Cocoon source code and
Metacello will download a zip archive from github. That's nice for all
users of Pillar but not for Pillar developers who would prefer a
read-write solution ;

2. Pillar depends on a read-write clone of the github repository. That's
nice for Pillar developers but not for Pillar users.
--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Thierry Goubier
2015-09-11 05:44:27 UTC
Permalink
Post by Damien Cassou
Post by Thierry Goubier
Post by Damien Cassou
- what happens if a Metacello description loads a project hosted in git
but I still want to be able to hack on this dependency. So, this
dependency should not be read-only for me
Can you give an example?
For example, Cocoon is a framework to facilitate handling of user
configuration files. We created Cocoon by extracting code from Pillar
and Pillar is still the only user of Cocoon. This means we evolve Pillar
and Cocoon in parallel. The configuration of Pillar requires Cocoon. As
far as I understand, there are 2-ways to describe this dependency if
1. Pillar depends on a read-only version of the Cocoon source code and
Metacello will download a zip archive from github. That's nice for all
users of Pillar but not for Pillar developers who would prefer a
read-write solution ;
2. Pillar depends on a read-write clone of the github repository. That's
nice for Pillar developers but not for Pillar users.
Easy:

stable version of pillar has github:// reference to Cocoon baseline.
Development version of pillar has gitfiletree:// reference to Cocoon
baseline.

Variant:

ConfigurationOfPillar in catalog browser has github:// reference to
Cocoon. Developpers of pillar write (Metacello baseline: 'pillar';
repository: 'gitfiletree://' ...) with a Pillar baseline referencing
gitfiletree for Cocoon.

Thierry
Peter Uhnák
2015-09-09 14:43:34 UTC
Permalink
Post by Damien Cassou
- a discussion about moving a smalltalkhub repository to git while
preserving history
I've migrated some time ago
http://forum.world.st/moving-to-git-and-preserving-monticello-history-td4806386.html

some (if not all) of the issues were resolved iirc, however since I didn't
need to migrate since then I don't know the current status.

- a discussion about which process to follow in which conditions
Post by Damien Cassou
(should I use GitFileTree or FileTree?)
Please note that GitFileTree didn't reliably work under Windows (problems
with ProcessWrapper or something; crashing a lot), don't know the current
status.

However from practical standpoint:
* with GitFileTree each MC commit inside Pharo creates a Git commit, so if
you change X packages within a single repo, you get also X git commits
* with FileTree you could pack them together more tightly but you need to
commit to git explicity.

but otherwise I don't see much practical difference

- what happens if a Metacello description loads a project hosted in git
Post by Damien Cassou
but I still want to be able to hack on this dependency. So, this
dependency should not be read-only for me
This is in my eyes very messy.... you could either add the package to a
repository after you have loaded your project,
or lock local repos... but it's quite a pain to keep everything in sync...
but I didn't have time to simplify my workflow here yet.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"GitFileTree"
Gofer new
url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
configurationOf: 'GitFileTree';
loadDevelopment.

"Dependency 1"
Metacello new
baseline: 'Dependency1';
repository: 'gitfiletree:///home/wherever/dependency1/repository';
lock.

"Dependency 2"
Metacello new
baseline: 'Project2';
repository: 'gitfiletree:///home/wherever/project2/repository';
lock.
"My Project"
Metacello new
baseline: 'MyProject';
repository: 'gitfiletree:///home/wherever/myProject/repository';
onConflict: [ :ex | ex allow ];
load.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Peter
Thierry Goubier
2015-09-09 15:24:57 UTC
Permalink
Post by Damien Cassou
- a discussion about moving a smalltalkhub repository to git while
Post by Damien Cassou
preserving history
I've migrated some time ago
http://forum.world.st/moving-to-git-and-preserving-monticello-history-td4806386.html
some (if not all) of the issues were resolved iirc, however since I didn't
need to migrate since then I don't know the current status.
- a discussion about which process to follow in which conditions
Post by Damien Cassou
(should I use GitFileTree or FileTree?)
Please note that GitFileTree didn't reliably work under Windows (problems
with ProcessWrapper or something; crashing a lot), don't know the current
status.
I don't either. I made some changes on the ProcessWrapper use, hoping for
the best, but I can't test :(
Post by Damien Cassou
* with GitFileTree each MC commit inside Pharo creates a Git commit, so if
you change X packages within a single repo, you get also X git commits
* with FileTree you could pack them together more tightly but you need to
commit to git explicity.
Dale has the idea of a project (grouping packages) with a single commit;
however the MC API has no notion of committing multiple packages in one
step except when dealing with dependencies. GitFileTree, for handling
package dependencies, has a mode for writing multiple packages and commit
only once, so one commit for multiple packages would be very easy to do. A
special api for Versionner?

Thierry
Thierry Goubier
2015-09-09 14:38:06 UTC
Permalink
Post by Damien Cassou
Hi,
today I wanted to have a look at how git integrates with Pharo. This is
what I found (mostly done by Thierry Goubier, thank you very much) and
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
But this is largely unfinished material. I contributed by adding a few
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress). Missing
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while
preserving history
- a discussion on how to write Metacello configurations for a project
on git and for a project which depends on a project on git.
- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems
to work fine. I sent 3 minor pull requests.
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
Dale proposed some tools: a diff parser/reader?

A reader for files with conflict markers.

Thierry
Post by Damien Cassou
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Alexandre Bergel
2015-09-10 15:40:20 UTC
Permalink
Hi!

I am not sure to understand. There is a fair amount of tools for got to deal with conflict. Sure, we could imagine compelling scenarios to have the conflict merger in Pharo. But I do not feel this is that necessary for now.

One question I have: is mcz the most appropriate? Why not simply doing a fileout of the package? And having one .st file per package.

Alexandre
Post by Thierry Goubier
Post by Damien Cassou
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
Thierry Goubier
2015-09-10 17:07:17 UTC
Permalink
Hi Alexandre,
Post by Alexandre Bergel
Hi!
I am not sure to understand. There is a fair amount of tools for got to
deal with conflict. Sure, we could imagine compelling scenarios to have
the conflict merger in Pharo. But I do not feel this is that necessary
for now.
Solving MC conflicts with tools like meld isn't fun. When it is for
Metacello version files, it's allmost impossible to correct properly.
Post by Alexandre Bergel
One question I have: is mcz the most appropriate? Why not simply doing a
fileout of the package? And having one .st file per package.
You need the mcz (in fact, Monticello) support for versions to have
Metacello: configurations, baselines and all the like. I think projects
like Seaside and Moose would not be doable without that.

Oh, by the way, for those who would like to try: git does not know how
to properly merge two conflicting class definitions in the chunk format,
so conflicts would still be present...

But, all well considered, relying only on the underlying vcs for
versions, but writing chunk files, could it work? With the gitfiletree
framework, all version / meta information is external to the source
files, so Metacello could use that and have everything it needs. Would
someone be interested by that?

Thierry
Post by Alexandre Bergel
Alexandre
Post by Damien Cassou
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
Alexandre Bergel
2015-09-10 17:37:11 UTC
Permalink
Solving MC conflicts with tools like meld isn't fun. When it is for Metacello version files, it's allmost impossible to correct properly.
I do not see why. It works well for other languages, I see no reason why it would not work in Pharo.
Post by Alexandre Bergel
One question I have: is mcz the most appropriate? Why not simply doing a
fileout of the package? And having one .st file per package.
You need the mcz (in fact, Monticello) support for versions to have Metacello: configurations, baselines and all the like. I think projects like Seaside and Moose would not be doable without that.
Well, if you have git, then the baseline is rather simple right?
But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that?
What do you mean by that? What you are suggesting, is it really more than fileout a source from a package? I am probably missing something obvious here.

Cheers,
Alexandre
Thierry
Post by Alexandre Bergel
Alexandre
Post by Damien Cassou
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
Thierry Goubier
2015-09-10 18:15:47 UTC
Permalink
Post by Alexandre Bergel
Post by Thierry Goubier
Solving MC conflicts with tools like meld isn't fun. When it is for
Metacello version files, it's allmost impossible to correct
properly.
I do not see why. It works well for other languages, I see no reason
why it would not work in Pharo.
That's because other languages have very poor, unstructured formats
which predates Smalltalk, i.e. source files. And an horrible mess of
unstructured information for building it: Makefiles, configure scripts,
maven, cmake, shell scripts, you name it.

Anything which tries to store anything more complex under text files in
git (json data, xml data, csv data) has the same problem.
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
One question I have: is mcz the most appropriate? Why not simply
doing a fileout of the package? And having one .st file per
package.
You need the mcz (in fact, Monticello) support for versions to have
Metacello: configurations, baselines and all the like. I think
projects like Seaside and Moose would not be doable without that.
Well, if you have git, then the baseline is rather simple right?
Yes. Part of the attractiveness of git is that: version information is
moved into the repository url instead of being in the mcz name.
Post by Alexandre Bergel
Post by Thierry Goubier
But, all well considered, relying only on the underlying vcs for
versions, but writing chunk files, could it work? With the
gitfiletree framework, all version / meta information is external
to the source files, so Metacello could use that and have
everything it needs. Would someone be interested by that?
What do you mean by that? What you are suggesting, is it really more
than fileout a source from a package? I am probably missing something
obvious here.
No, it is just a fileout. Apart from dependencies, but nobody uses them
except for SLICES.

There are a few queries you can do on a git repository (search for
method versions, class definition changes) where you have to use the
filetree format and the chunk format won't work.

But, honestly, nobody needs that: I am the only user in the Pharo
community (i.e. you need AltBrowser + GitFileTree for that feature).

Ah, yes, for the filetree format: it's a lot easier to browse the
filetree format than the chunk on github:/, bitbucket:/, gitosis,
gitlab, etc... It is also reasonably portable among dialects (ST/X,
Squeak, Pharo, Gemstone, VW?) But it has a problem with long file names
under windows. And it may be slow to write plenty of small files.

Thierry
Post by Alexandre Bergel
Cheers, Alexandre
Post by Thierry Goubier
Thierry
Post by Alexandre Bergel
Alexandre
Le 9 sept. 2015 à 11:38, Thierry Goubier
Post by Damien Cassou
- A tool to resolve merge conflicts in Pharo. We should reuse
the diff widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
Alexandre Bergel
2015-09-10 18:29:15 UTC
Permalink
Post by Thierry Goubier
But, all well considered, relying only on the underlying vcs for
versions, but writing chunk files, could it work? With the
gitfiletree framework, all version / meta information is external
to the source files, so Metacello could use that and have
everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be .mcs that is like .mcz but without all the metadata? This means that we will need another UI since Monticello will not work.
Can you estimate the amount of work to do?

Alexandre
Thierry Goubier
2015-09-10 19:04:40 UTC
Permalink
Post by Alexandre Bergel
Post by Thierry Goubier
But, all well considered, relying only on the underlying vcs for
versions, but writing chunk files, could it work? With the
gitfiletree framework, all version / meta information is external
to the source files, so Metacello could use that and have
everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be .mcs that
is like .mcz but without all the metadata?
That would be that. The mcs would be the chunk format that Pharo and all
Smalltalks have (i.e. fileouts).
Post by Alexandre Bergel
This means that we will need
another UI since Monticello will not work.
No, it would simply be another type of repository for Monticello. I have
already done the work for GitFileTree (recreate a MC-like API even if
the metadata comes from git instead of the mcz), and you would reuse that.

It would be totally transparent to you. Metacello, Gofer, Configurations
would work.
Post by Alexandre Bergel
Can you estimate the amount of work to do?
I'd start from GitFileTree, isolate the git commands and the MC API and
copy them to the new repository type, add a chunk reader over a zip
archive, and add the chunk writer. I'd reuse the GitFileTree repository
inspector because it is already designed for that.

For someone who knows a bit the internals of a MC repository, it
wouldn't take long.

Shouldn't forget to have a good chunk of tests cases and sample
repositories: filetree would be my reference there.

Thierry
Post by Alexandre Bergel
Alexandre
Alexandre Bergel
2015-09-11 13:33:16 UTC
Permalink
[ answer in the mailing list since it may interest other ]

Another problem would be the synchronization between the image and the source code stored on disk. For example, I should never do a git pull within a xterm command, because the image will not be sync.

Alexandre
Salut Alexandre,
je creuse encore un peu l'idée de l'autre format et...
- Le format "chunk/fileout" de Pharo ne comporte pas les infos nécessaires à Monticello; le même fichier "version" si embêtant sous git est dans le mcz (et s'il était mis dans le .st, on aurait les mêmes conflits sous git merge, mais sans doute plus compliqué).
- Si on passe sur un format n'ayant pas cette info de version, il faut absolument passer par git pour la récupérer. Or git et windows ça ne marche pas encore correctement. Ça limiterait le nouveau format à Mac et Linux :(
Bienvenue dans ce bazar très désagréable à contempler.
Thierry
.
moi je me demanderais juste une chose, du point de vue que j'ai quand je discute transfert de technologie : est-ce que ça sert à quelque chose d'investir là-dedans ?
Ben j’aimerai pouvoir utiliser Git au lieu de SmalltalkHub.
En gros, FileTree marche très bien (avec des ratés sous windows en cours de résolution), GitFileTree marche très bien (avec des ratés sous windows), le merge driver marche très bien. Pourquoi veux-tu changer de format ?
Pour ne pas à avoir à modifier le .gitconfig et le .gitattributes.
J’ai un nouveau cours où j’enseigne Pharo. Mais je ne me vois pas vraiment leur dire de suivre la procédure sur https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche mais c’est particulièrement complexe.
Alexandre
- Corriger ProcessWrapper sous Windows
ou
- Travailler sur l'intégration de libcgit
et
- Travailler sur un outil de résolution de conflit git sous Pharo (pour éviter d'avoir à utiliser meld et compagnie).
Tu sais, je peux te vendre* ce que serait la chaîne git parfaite pour Pharo, et je ne te parlerais pas du format ou d'en changer.
* te faire le pitch investisseur / VC
** C'est vraiment la merde de rajouter des types supplémentaires de repository dans Pharo, donc c'est aussi pour ça que je ne l'encourage pas trop.
*** Mais en même temps, c'est un sujet très important, donc c'est bien qu'on en discute.
Thierry
[ This is a private message ]
This is a topic very important for me. Would you like to guide an
engineer if I get one? Milton is a very competent engineer. I really
would like this topic move on.
Cheers,
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sep 10, 2015, at 4:04 PM, Thierry Goubier
Post by Alexandre Bergel
Post by Thierry Goubier
But, all well considered, relying only on the underlying vcs for
versions, but writing chunk files, could it work? With the
gitfiletree framework, all version / meta information is external
to the source files, so Metacello could use that and have
everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be .mcs that
is like .mcz but without all the metadata?
That would be that. The mcs would be the chunk format that Pharo and
all Smalltalks have (i.e. fileouts).
Post by Alexandre Bergel
This means that we will need
another UI since Monticello will not work.
No, it would simply be another type of repository for Monticello. I
have already done the work for GitFileTree (recreate a MC-like API
even if the metadata comes from git instead of the mcz), and you would
reuse that.
It would be totally transparent to you. Metacello, Gofer,
Configurations would work.
Post by Alexandre Bergel
Can you estimate the amount of work to do?
I'd start from GitFileTree, isolate the git commands and the MC API
and copy them to the new repository type, add a chunk reader over a
zip archive, and add the chunk writer. I'd reuse the GitFileTree
repository inspector because it is already designed for that.
For someone who knows a bit the internals of a MC repository, it
wouldn't take long.
Shouldn't forget to have a good chunk of tests cases and sample
repositories: filetree would be my reference there.
Thierry
Post by Alexandre Bergel
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thierry Goubier
2015-09-11 13:38:44 UTC
Permalink
Post by Alexandre Bergel
[ answer in the mailing list since it may interest other ]
Another problem would be the synchronization between the image and the
source code stored on disk. For example, I should never do a git pull
within a xterm command, because the image will not be sync.
No, this is not an issue. By design, the state of your code in your image
is not kept in sync with a repository; you can be n versions behind the
latest in the repository, if you like. This is the case with Smalltalkhub.
A pull in git only amounts to a more extensive refresh in a Smalltalkhub
repository.

Thierry
Post by Alexandre Bergel
Alexandre
Salut Alexandre,
je creuse encore un peu l'idée de l'autre format et...
- Le format "chunk/fileout" de Pharo ne comporte pas les infos
nécessaires à Monticello; le même fichier "version" si embêtant sous git
est dans le mcz (et s'il était mis dans le .st, on aurait les mêmes
conflits sous git merge, mais sans doute plus compliqué).
- Si on passe sur un format n'ayant pas cette info de version, il faut
absolument passer par git pour la récupérer. Or git et windows ça ne marche
pas encore correctement. Ça limiterait le nouveau format à Mac et Linux :(
Bienvenue dans ce bazar trÚs désagréable à contempler.
Thierry
.
moi je me demanderais juste une chose, du point de vue que j'ai quand
je discute transfert de technologie : est-ce que ça sert à quelque chose
d'investir là-dedans ?
Ben j’aimerai pouvoir utiliser Git au lieu de SmalltalkHub.
En gros, FileTree marche trÚs bien (avec des ratés sous windows en
cours de résolution), GitFileTree marche trÚs bien (avec des ratés sous
windows), le merge driver marche trÚs bien. Pourquoi veux-tu changer de
format ?
Pour ne pas à avoir à modifier le .gitconfig et le .gitattributes.
J’ai un nouveau cours où j’enseigne Pharo. Mais je ne me vois pas
vraiment leur dire de suivre la procédure sur
https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche
mais c’est particuliÚrement complexe.
Alexandre
- Corriger ProcessWrapper sous Windows
ou
- Travailler sur l'intégration de libcgit
et
- Travailler sur un outil de résolution de conflit git sous Pharo
(pour éviter d'avoir à utiliser meld et compagnie).
Tu sais, je peux te vendre* ce que serait la chaîne git parfaite pour
Pharo, et je ne te parlerais pas du format ou d'en changer.
* te faire le pitch investisseur / VC
** C'est vraiment la merde de rajouter des types supplémentaires de
repository dans Pharo, donc c'est aussi pour ça que je ne l'encourage pas
trop.
*** Mais en même temps, c'est un sujet trÚs important, donc c'est bien
qu'on en discute.
Thierry
[ This is a private message ]
This is a topic very important for me. Would you like to guide an
engineer if I get one? Milton is a very competent engineer. I really
would like this topic move on.
Cheers,
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sep 10, 2015, at 4:04 PM, Thierry Goubier
Post by Alexandre Bergel
Post by Thierry Goubier
But, all well considered, relying only on the underlying vcs for
versions, but writing chunk files, could it work? With the
gitfiletree framework, all version / meta information is external
to the source files, so Metacello could use that and have
everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be .mcs
that
Post by Alexandre Bergel
is like .mcz but without all the metadata?
That would be that. The mcs would be the chunk format that Pharo and
all Smalltalks have (i.e. fileouts).
Post by Alexandre Bergel
This means that we will need
another UI since Monticello will not work.
No, it would simply be another type of repository for Monticello. I
have already done the work for GitFileTree (recreate a MC-like API
even if the metadata comes from git instead of the mcz), and you
would
reuse that.
It would be totally transparent to you. Metacello, Gofer,
Configurations would work.
Post by Alexandre Bergel
Can you estimate the amount of work to do?
I'd start from GitFileTree, isolate the git commands and the MC API
and copy them to the new repository type, add a chunk reader over a
zip archive, and add the chunk writer. I'd reuse the GitFileTree
repository inspector because it is already designed for that.
For someone who knows a bit the internals of a MC repository, it
wouldn't take long.
Shouldn't forget to have a good chunk of tests cases and sample
repositories: filetree would be my reference there.
Thierry
Post by Alexandre Bergel
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel
2015-09-11 13:47:50 UTC
Permalink
But this add a serious indirection layer. In Java, since there is no image, doing a pull update your code. In Pharo, it would simply update the git repo, without updating the code in your image. What’s happens if I modify the code in my image and do a git pull? I will have conflict between my image and the git repo. That was the very first scenario I did when I tried Git. No no no, that is completely broken.

Alexandre
Post by Alexandre Bergel
[ answer in the mailing list since it may interest other ]
Another problem would be the synchronization between the image and the source code stored on disk. For example, I should never do a git pull within a xterm command, because the image will not be sync.
No, this is not an issue. By design, the state of your code in your image is not kept in sync with a repository; you can be n versions behind the latest in the repository, if you like. This is the case with Smalltalkhub. A pull in git only amounts to a more extensive refresh in a Smalltalkhub repository.
Thierry
Alexandre
Salut Alexandre,
je creuse encore un peu l'idée de l'autre format et...
- Le format "chunk/fileout" de Pharo ne comporte pas les infos nécessaires à Monticello; le même fichier "version" si embêtant sous git est dans le mcz (et s'il était mis dans le .st, on aurait les mêmes conflits sous git merge, mais sans doute plus compliqué).
- Si on passe sur un format n'ayant pas cette info de version, il faut absolument passer par git pour la récupérer. Or git et windows ça ne marche pas encore correctement. Ça limiterait le nouveau format à Mac et Linux :(
Bienvenue dans ce bazar très désagréable à contempler.
Thierry
.
moi je me demanderais juste une chose, du point de vue que j'ai quand je discute transfert de technologie : est-ce que ça sert à quelque chose d'investir là-dedans ?
Ben j’aimerai pouvoir utiliser Git au lieu de SmalltalkHub.
En gros, FileTree marche très bien (avec des ratés sous windows en cours de résolution), GitFileTree marche très bien (avec des ratés sous windows), le merge driver marche très bien. Pourquoi veux-tu changer de format ?
Pour ne pas à avoir à modifier le .gitconfig et le .gitattributes.
J’ai un nouveau cours où j’enseigne Pharo. Mais je ne me vois pas vraiment leur dire de suivre la procédure sur https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche mais c’est particulièrement complexe.
Alexandre
- Corriger ProcessWrapper sous Windows
ou
- Travailler sur l'intégration de libcgit
et
- Travailler sur un outil de résolution de conflit git sous Pharo (pour éviter d'avoir à utiliser meld et compagnie).
Tu sais, je peux te vendre* ce que serait la chaîne git parfaite pour Pharo, et je ne te parlerais pas du format ou d'en changer.
* te faire le pitch investisseur / VC
** C'est vraiment la merde de rajouter des types supplémentaires de repository dans Pharo, donc c'est aussi pour ça que je ne l'encourage pas trop.
*** Mais en même temps, c'est un sujet très important, donc c'est bien qu'on en discute.
Thierry
[ This is a private message ]
This is a topic very important for me. Would you like to guide an
engineer if I get one? Milton is a very competent engineer. I really
would like this topic move on.
Cheers,
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sep 10, 2015, at 4:04 PM, Thierry Goubier
Post by Alexandre Bergel
Post by Thierry Goubier
But, all well considered, relying only on the underlying vcs for
versions, but writing chunk files, could it work? With the
gitfiletree framework, all version / meta information is external
to the source files, so Metacello could use that and have
everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be .mcs that
is like .mcz but without all the metadata?
That would be that. The mcs would be the chunk format that Pharo and
all Smalltalks have (i.e. fileouts).
Post by Alexandre Bergel
This means that we will need
another UI since Monticello will not work.
No, it would simply be another type of repository for Monticello. I
have already done the work for GitFileTree (recreate a MC-like API
even if the metadata comes from git instead of the mcz), and you would
reuse that.
It would be totally transparent to you. Metacello, Gofer,
Configurations would work.
Post by Alexandre Bergel
Can you estimate the amount of work to do?
I'd start from GitFileTree, isolate the git commands and the MC API
and copy them to the new repository type, add a chunk reader over a
zip archive, and add the chunk writer. I'd reuse the GitFileTree
repository inspector because it is already designed for that.
For someone who knows a bit the internals of a MC repository, it
wouldn't take long.
Shouldn't forget to have a good chunk of tests cases and sample
repositories: filetree would be my reference there.
Thierry
Post by Alexandre Bergel
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thierry Goubier
2015-09-11 14:07:53 UTC
Permalink
Post by Alexandre Bergel
But this add a serious indirection layer. In Java, since there is no
image, doing a pull update your code. In Pharo, it would simply update the
git repo, without updating the code in your image. What’s happens if I
modify the code in my image and do a git pull? I will have conflict between
my image and the git repo. That was the very first scenario I did when I
tried Git. No no no, that is completely broken.
Come on, you know that your java code is a dead thing, without any live
capability, and going this way would be a huge step backward in Smalltalk.

Speaking of Roassal, I'm sure that if I start developping on it, after a
week, I'm out of sync for at least ten version of it and unable to merge
back my fixes in it, and that would be with Smalltalkhub. Me on a git
workflow with Roassal? Piece of cake.

Remember that you work differently on git and over smalltalkhub. In
Smalltalkhub, you avoid branches and have only one master; in git you'll
have plenty of branches and avoid doing work directly on master, because of
the out of sync effects (and frequent merges).

Thierry
Post by Alexandre Bergel
Alexandre
Post by Alexandre Bergel
[ answer in the mailing list since it may interest other ]
Another problem would be the synchronization between the image and the
source code stored on disk. For example, I should never do a git pull
within a xterm command, because the image will not be sync.
Post by Alexandre Bergel
No, this is not an issue. By design, the state of your code in your
image is not kept in sync with a repository; you can be n versions behind
the latest in the repository, if you like. This is the case with
Smalltalkhub. A pull in git only amounts to a more extensive refresh in a
Smalltalkhub repository.
Post by Alexandre Bergel
Thierry
Alexandre
On Sep 11, 2015, at 4:56 AM, Thierry Goubier <
Salut Alexandre,
je creuse encore un peu l'idée de l'autre format et...
- Le format "chunk/fileout" de Pharo ne comporte pas les infos
nécessaires à Monticello; le même fichier "version" si embêtant sous git
est dans le mcz (et s'il était mis dans le .st, on aurait les mêmes
conflits sous git merge, mais sans doute plus compliqué).
Post by Alexandre Bergel
- Si on passe sur un format n'ayant pas cette info de version, il faut
absolument passer par git pour la récupérer. Or git et windows ça ne marche
pas encore correctement. Ça limiterait le nouveau format à Mac et Linux :(
Post by Alexandre Bergel
Bienvenue dans ce bazar trÚs désagréable à contempler.
Thierry
.
moi je me demanderais juste une chose, du point de vue que j'ai
quand je discute transfert de technologie : est-ce que ça sert à quelque
chose d'investir là-dedans ?
Post by Alexandre Bergel
Ben j’aimerai pouvoir utiliser Git au lieu de SmalltalkHub.
En gros, FileTree marche trÚs bien (avec des ratés sous windows en
cours de résolution), GitFileTree marche trÚs bien (avec des ratés sous
windows), le merge driver marche trÚs bien. Pourquoi veux-tu changer de
format ?
Post by Alexandre Bergel
Pour ne pas à avoir à modifier le .gitconfig et le .gitattributes.
J’ai un nouveau cours où j’enseigne Pharo. Mais je ne me vois pas
vraiment leur dire de suivre la procédure sur
https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche
mais c’est particuliÚrement complexe.
Post by Alexandre Bergel
Alexandre
- Corriger ProcessWrapper sous Windows
ou
- Travailler sur l'intégration de libcgit
et
- Travailler sur un outil de résolution de conflit git sous Pharo
(pour éviter d'avoir à utiliser meld et compagnie).
Post by Alexandre Bergel
Tu sais, je peux te vendre* ce que serait la chaîne git parfaite
pour Pharo, et je ne te parlerais pas du format ou d'en changer.
Post by Alexandre Bergel
* te faire le pitch investisseur / VC
** C'est vraiment la merde de rajouter des types supplémentaires de
repository dans Pharo, donc c'est aussi pour ça que je ne l'encourage pas
trop.
Post by Alexandre Bergel
*** Mais en même temps, c'est un sujet trÚs important, donc c'est
bien qu'on en discute.
Post by Alexandre Bergel
Thierry
[ This is a private message ]
This is a topic very important for me. Would you like to guide an
engineer if I get one? Milton is a very competent engineer. I really
would like this topic move on.
Cheers,
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sep 10, 2015, at 4:04 PM, Thierry Goubier
Post by Alexandre Bergel
Post by Thierry Goubier
But, all well considered, relying only on the underlying vcs
for
Post by Alexandre Bergel
Post by Alexandre Bergel
Post by Thierry Goubier
versions, but writing chunk files, could it work? With the
gitfiletree framework, all version / meta information is
external
Post by Alexandre Bergel
Post by Alexandre Bergel
Post by Thierry Goubier
to the source files, so Metacello could use that and have
everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be
.mcs that
Post by Alexandre Bergel
Post by Alexandre Bergel
is like .mcz but without all the metadata?
That would be that. The mcs would be the chunk format that Pharo
and
Post by Alexandre Bergel
all Smalltalks have (i.e. fileouts).
Post by Alexandre Bergel
This means that we will need
another UI since Monticello will not work.
No, it would simply be another type of repository for Monticello. I
have already done the work for GitFileTree (recreate a MC-like API
even if the metadata comes from git instead of the mcz), and you
would
Post by Alexandre Bergel
reuse that.
It would be totally transparent to you. Metacello, Gofer,
Configurations would work.
Post by Alexandre Bergel
Can you estimate the amount of work to do?
I'd start from GitFileTree, isolate the git commands and the MC API
and copy them to the new repository type, add a chunk reader over a
zip archive, and add the chunk writer. I'd reuse the GitFileTree
repository inspector because it is already designed for that.
For someone who knows a bit the internals of a MC repository, it
wouldn't take long.
Shouldn't forget to have a good chunk of tests cases and sample
repositories: filetree would be my reference there.
Thierry
Post by Alexandre Bergel
Alexandre
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel
2015-09-10 23:52:09 UTC
Permalink
Hi!

I am confused. What is said on https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
is different than what I can read on https://github.com/ThierryGoubier/GitFileTree-MergeDriver

Do I need to modify .gitattributes and .gitconfig?

Alexandre
Post by Damien Cassou
Hi,
today I wanted to have a look at how git integrates with Pharo. This is
what I found (mostly done by Thierry Goubier, thank you very much) and
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
But this is largely unfinished material. I contributed by adding a few
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress). Missing
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while
preserving history
- a discussion on how to write Metacello configurations for a project
on git and for a project which depends on a project on git.
- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems
to work fine. I sent 3 minor pull requests.
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thierry Goubier
2015-09-11 04:51:29 UTC
Permalink
Post by Alexandre Bergel
Hi!
I am confused. What is said on https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
is different than what I can read on https://github.com/ThierryGoubier/GitFileTree-MergeDriver
In what way? The GitAndPharo chapter is a bit out of date and incomplete
Post by Alexandre Bergel
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when
the merge driver is installed.

Thierry
Post by Alexandre Bergel
Alexandre
Post by Damien Cassou
Hi,
today I wanted to have a look at how git integrates with Pharo. This is
what I found (mostly done by Thierry Goubier, thank you very much) and
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
But this is largely unfinished material. I contributed by adding a few
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress). Missing
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while
preserving history
- a discussion on how to write Metacello configurations for a project
on git and for a project which depends on a project on git.
- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems
to work fine. I sent 3 minor pull requests.
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
Alexandre Bergel
2015-09-11 13:28:36 UTC
Permalink
Post by Alexandre Bergel
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed.
Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git.
More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data.

Alexandre
Thierry
Post by Alexandre Bergel
Alexandre
Post by Damien Cassou
Hi,
today I wanted to have a look at how git integrates with Pharo. This is
what I found (mostly done by Thierry Goubier, thank you very much) and
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
But this is largely unfinished material. I contributed by adding a few
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress). Missing
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while
preserving history
- a discussion on how to write Metacello configurations for a project
on git and for a project which depends on a project on git.
- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems
to work fine. I sent 3 minor pull requests.
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thierry Goubier
2015-09-11 13:35:39 UTC
Permalink
Post by Thierry Goubier
Post by Thierry Goubier
Post by Alexandre Bergel
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when
the merge driver is installed.
Ok, but why do we need this ? What I understand is to merge conflicts with
metadata of .mcz, which are useless in Git.
Yes and no. They are useless in an ideal world where everybody is using git
or an equivalent (fossil, hg, svn). But they are very usefull now to get
non-git users to keep using the packages (the tandem filetree/gitfiletree).
Post by Thierry Goubier
More I think about it, more I think that we need to go toward a lighter
version of .mcz file, without the meta-data.
I agree on the target, but.

git support on windows is not there yet, and any format without metadata
would be Linux and Mac only at the moment.

I do believe that external commands on Windows is/should be a priority, but
I can only wish for it. libcgit would also solve the problem of git support
(but would restrict it to git only).

Thierry
Post by Thierry Goubier
Alexandre
Post by Thierry Goubier
Thierry
Post by Alexandre Bergel
Alexandre
Post by Damien Cassou
Hi,
today I wanted to have a look at how git integrates with Pharo. This is
what I found (mostly done by Thierry Goubier, thank you very much) and
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
But this is largely unfinished material. I contributed by adding a few
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress). Missing
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while
preserving history
- a discussion on how to write Metacello configurations for a project
on git and for a project which depends on a project on git.
- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems
to work fine. I sent 3 minor pull requests.
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel
2015-09-11 13:45:07 UTC
Permalink
But making sure that people for a given project can commit either to a git repo to a smalltalkhub significantly complexify the thing. And at the end, we will always have people who stay in smalltalkhub because it is much simpler than git.

Several times I wanted to migrate to git, but the burden of Monticello metadata make me stay with SmalltalkHub. We are missing a big train…

Alexandre
Post by Alexandre Bergel
Post by Alexandre Bergel
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed.
Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git.
Yes and no. They are useless in an ideal world where everybody is using git or an equivalent (fossil, hg, svn). But they are very usefull now to get non-git users to keep using the packages (the tandem filetree/gitfiletree).
More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data.
I agree on the target, but.
git support on windows is not there yet, and any format without metadata would be Linux and Mac only at the moment.
I do believe that external commands on Windows is/should be a priority, but I can only wish for it. libcgit would also solve the problem of git support (but would restrict it to git only).
Thierry
Alexandre
Thierry
Post by Alexandre Bergel
Alexandre
Post by Damien Cassou
Hi,
today I wanted to have a look at how git integrates with Pharo. This is
what I found (mostly done by Thierry Goubier, thank you very much) and
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
But this is largely unfinished material. I contributed by adding a few
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress). Missing
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while
preserving history
- a discussion on how to write Metacello configurations for a project
on git and for a project which depends on a project on git.
- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems
to work fine. I sent 3 minor pull requests.
- A tool to resolve merge conflicts in Pharo. We should reuse the diff
widget we have.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thierry Goubier
2015-09-11 14:02:19 UTC
Permalink
Post by Alexandre Bergel
But making sure that people for a given project can commit either to a git
repo to a smalltalkhub significantly complexify the thing. And at the end,
we will always have people who stay in smalltalkhub because it is much
simpler than git.
Of course it makes things a lot more complex. But, honestly, for anything
complex (with branches and all), I would never use smalltalkhub. Not
anymore. Especially given the naming bugs you have with Monticello, and the
complexity of writing configurations for it.
Post by Alexandre Bergel
Several times I wanted to migrate to git, but the burden of Monticello
metadata make me stay with SmalltalkHub. We are missing a big train

Not that much. The system is doing more or less fine so far. Smalltalkhub
for the core, git for some of us, and it works really well.

Unless you're Linus Torvalds, you don't throw your community on a new
system overnight ;)

Thierry
Post by Alexandre Bergel
Alexandre
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of
when the merge driver is installed.
Post by Alexandre Bergel
Ok, but why do we need this ? What I understand is to merge conflicts
with metadata of .mcz, which are useless in Git.
Post by Alexandre Bergel
Yes and no. They are useless in an ideal world where everybody is using
git or an equivalent (fossil, hg, svn). But they are very usefull now to
get non-git users to keep using the packages (the tandem
filetree/gitfiletree).
Post by Alexandre Bergel
More I think about it, more I think that we need to go toward a lighter
version of .mcz file, without the meta-data.
Post by Alexandre Bergel
I agree on the target, but.
git support on windows is not there yet, and any format without metadata
would be Linux and Mac only at the moment.
Post by Alexandre Bergel
I do believe that external commands on Windows is/should be a priority,
but I can only wish for it. libcgit would also solve the problem of git
support (but would restrict it to git only).
Post by Alexandre Bergel
Thierry
Alexandre
Post by Thierry Goubier
Thierry
Post by Alexandre Bergel
Alexandre
Post by Damien Cassou
Hi,
today I wanted to have a look at how git integrates with Pharo. This
is
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
what I found (mostly done by Thierry Goubier, thank you very much)
and
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/GitAndPharo/GitAndPharo.html
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
But this is largely unfinished material. I contributed by adding a
few
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
things here and there but not much. If you have some experience,
please share it there
(https://github.com/SquareBracketAssociates/PharoInProgress).
Missing
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while
preserving history
- a discussion on how to write Metacello configurations for a
project
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
on git and for a project which depends on a project on git.
- there is a nice git merge driver
(https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It
seems
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
to work fine. I sent 3 minor pull requests.
- A tool to resolve merge conflicts in Pharo. We should reuse the
diff
Post by Alexandre Bergel
Post by Thierry Goubier
Post by Alexandre Bergel
Post by Damien Cassou
widget we have.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Continue reading on narkive:
Loading...