4 ms·

You are missing some background. First, Pharo uses libgit2 and provides its own merging mechanism to this library. It understands the code much better than plai

You are missing some background. First, Pharo uses libgit2 and provides its own merging mechanism to this library. It understands the code much better than plain Git, so code merging usually has fewer conflicts. Second, for Pharo, the code (classes, methods...) are living objects. These objects are the working copy Pharo deals with. Not with the files. So it mostly works only with this object working copy + .git database. Another working copy of files (which other developers would use for editing, files outside of the .git directory) is just an additional source of problems and conflicts. Pharo has a nice Git integration, and they spent a lot of time on making it work really well. So it has functions like browsing the history of one particular method etc. You are discussing already solved problems.

galaxyLogic 5y ago
> it has functions like browsing the history of one particular method etc. That is great functionality I think. Much better than basic git where changes are just changes to a set of lines. The unit of software should be classes and methods, not files. The reason git can't do this is that it is language neutral. However what I find interesting is that there is a corollary between git commits and Smalltalk snapshots. It would be great if we could "merge" Smalltalk images by checking out specific git commits and merging them together. The result would then be all the source-code in your current Smalltalk image. It is difficult if not impossible to merge two Smalltalk images. Yet it would be useful to know what are the conflicts if any between two images. Maybe Pharo already provides something in that direction?
- igouy 5y ago
  > … if we could "merge" Smalltalk images … merge two Smalltalk images … what are the conflicts … Merge changes, not images. Even back in 1983, "Smalltalk-80: The Interactive Programming Environment" "check conflicts A prompter appears in which you type the name of a changes file. When you choose the yellow button command accept, an analysis is done of all the items in the change management browser menu to see if any of them refer to the same message selector, but specify different definitions." page 472 http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...

galaxyLogic 5y ago

> it has functions like browsing the history of one particular method etc. That is great functionality I think. Much better than basic git where changes are just changes to a set of lines. The unit of software should be classes and methods, not files. The reason git can't do this is that it is language neutral. However what I find interesting is that there is a corollary between git commits and Smalltalk snapshots. It would be great if we could "merge" Smalltalk images by checking out specific git commits and merging them together. The result would then be all the source-code in your current Smalltalk image. It is difficult if not impossible to merge two Smalltalk images. Yet it would be useful to know what are the conflicts if any between two images. Maybe Pharo already provides something in that direction?

igouy 5y ago
> … if we could "merge" Smalltalk images … merge two Smalltalk images … what are the conflicts … Merge changes, not images. Even back in 1983, "Smalltalk-80: The Interactive Programming Environment" "check conflicts A prompter appears in which you type the name of a changes file. When you choose the yellow button command accept, an analysis is done of all the items in the change management browser menu to see if any of them refer to the same message selector, but specify different definitions." page 472 http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...