Having a look at Git+Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Having a look at Git+Pharo

abergel
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



> On Sep 11, 2015, at 10:35 AM, Thierry Goubier <[hidden email]> wrote:
>
>
>
> 2015-09-11 15:28 GMT+02:00 Alexandre Bergel <[hidden email]>:
>
> >> 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
> >
> >>
> >> Alexandre
> >>
> >>> On Sep 9, 2015, at 11:04 AM, Damien Cassou <[hidden email]> wrote:
> >>>
> >>> 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
> >>>
> >>
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: Having a look at Git+Pharo

abergel
In reply to this post by Thierry Goubier
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



> On Sep 11, 2015, at 10:38 AM, Thierry Goubier <[hidden email]> wrote:
>
>
>
> Le 11 septembre 2015 15:33, Alexandre Bergel <[hidden email]> a écrit :
> [ 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
>
>
>
> > On Sep 11, 2015, at 4:56 AM, Thierry Goubier <[hidden email]> wrote:
> >
> > 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
> > .
> >
> > 2015-09-11 1:47 GMT+02:00 Alexandre Bergel <[hidden email]>:
> > > 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
> >
> >
> > >
> > > L'investissement qui fait sens pour moi est:
> > > - 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
> > >
> > > Le 10/09/2015 23:11, Alexandre Bergel a écrit :
> > >> [ 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
> > >>> <[hidden email] <mailto:[hidden email]>> wrote:
> > >>>
> > >>> Le 10/09/2015 20:29, Alexandre Bergel a écrit :
> > >>>>>>> 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).
> > >>>
> > >>>> 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.
> > >>>
> > >>>> 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
> > >>>
> > >>>> Alexandre
> > >>>
> > >>>
> > >>
> > >
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: Having a look at Git+Pharo

Thierry Goubier
In reply to this post by abergel


2015-09-11 15:45 GMT+02:00 Alexandre Bergel <[hidden email]>:
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.
 

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


Alexandre



> On Sep 11, 2015, at 10:35 AM, Thierry Goubier <[hidden email]> wrote:
>
>
>
> 2015-09-11 15:28 GMT+02:00 Alexandre Bergel <[hidden email]>:
>
> >> 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
> >
> >>
> >> Alexandre
> >>
> >>> On Sep 9, 2015, at 11:04 AM, Damien Cassou <[hidden email]> wrote:
> >>>
> >>> 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
> >>>
> >>
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





Reply | Threaded
Open this post in threaded view
|

Re: Having a look at Git+Pharo

Thierry Goubier
In reply to this post by abergel


2015-09-11 15:47 GMT+02:00 Alexandre Bergel <[hidden email]>:
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
 

Alexandre



> On Sep 11, 2015, at 10:38 AM, Thierry Goubier <[hidden email]> wrote:
>
>
>
> Le 11 septembre 2015 15:33, Alexandre Bergel <[hidden email]> a écrit :
> [ 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
>
>
>
> > On Sep 11, 2015, at 4:56 AM, Thierry Goubier <[hidden email]> wrote:
> >
> > 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
> > .
> >
> > 2015-09-11 1:47 GMT+02:00 Alexandre Bergel <[hidden email]>:
> > > 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
> >
> >
> > >
> > > L'investissement qui fait sens pour moi est:
> > > - 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
> > >
> > > Le 10/09/2015 23:11, Alexandre Bergel a écrit :
> > >> [ 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
> > >>> <[hidden email] <mailto:[hidden email]>> wrote:
> > >>>
> > >>> Le 10/09/2015 20:29, Alexandre Bergel a écrit :
> > >>>>>>> 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).
> > >>>
> > >>>> 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.
> > >>>
> > >>>> 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
> > >>>
> > >>>> Alexandre
> > >>>
> > >>>
> > >>
> > >
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





12