> On 01 Dec 2014, at 21:15, Thierry Goubier <[email protected]> wrote: > > Le 01/12/2014 20:25, Dale Henrichs a écrit : >> >> >> On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier >> <[email protected] <mailto:[email protected]>> wrote: >> >> Le 01/12/2014 19:21, Esteban Lorenzano a écrit : >> >> >> also, in a point (not now, but eventually)… we will need to drop >> something. The idea of keeping anything ad eternum just does not >> scales. >> >> >> But it's a good way of delaying git integration in the Pharo >> platform by having to redesign the file format as well. >> >> >> Thierry, >> >> Not sure if you are being sarcastic here:) > > I wish I was :( > >> I just don't see how the current FileTree format "delays git integration >> in the Pharo platform." > > This is exactly my point. It works, it is cross-platform (mcz to FileTree and > back), it has a significant bug squashing done, it's stable. > > Yes, it's not perfect. Metadata is noisy in github output, it used to cause > problem when merging, and there is issues with very long path and file names. > > However, all discussions about changing the file format around Pharo brings > no convincing arguments... just cosmetic changes, which basically says: lets > do the same as before, but not compatible and with a new code base so that we > can have our own new bugs. > > (If I had to redesign the file format for git use, I'd consider FileOut with > a better parser, and alphabetical ordering: minimal code for reading and > writing. But I'd loose some of the features that tODE has when querying the > git logs). > >> I consider git integrated into tODE and tODE uses FileTree. >> >> Perhaps it's a matter of approach. In tODE the git support is NOT >> centered on the package browser ... the git support is built into the >> "system browser" so you can look at git history from a class, method OR >> package perspective ... Other perspectives are possible as it is >> relatively straightforward to pull up the git history of any directory >> or file ... and git integration should include the ability to view diffs >> and merge non-smalltalk files... > > I agree. But you are at the point where you just say: > > "libgit2 or GitFileTree are just means to an end: better tools to tap in the > power of git and do something interesting with it." > > Look the situation of Pharo... They are still trying to get the > infrastructure working. Yes, libgit2 will be better than GitFileTree, but > barely, and how many years will Pharo have invested for that? In the mean > time, what should I invest in? A GitFileTree which will be wasted anyway? And > in a few years time, will NativeBoost still be in use? Or replaced by FFI and > LowCode? With libgit2 reimplemented? With no support of libgit2 on ARM? > > And for what? The goal is to hide git behind any package and source > management tools we have in the image, after all.
well, no. the goal is to not needing to install git command line to use it (is a requirement: pharo needs to keep being as portable and independent as always) :) from my point of view, I’m quite happy with gitfiletree. I will just intend to make it work without OSProcess. but in other discussions. Yes, we will need to stabilise things in a point. I’m not happy with general status of… well, a lot of things. And not in status of stability (most of them work really well), but I’m working to try to ensure the maintainability in the long way… and that includes time to time needing to admit that we cannot maintain everything (thus my push of (git)filetree and the use of git in general) Esteban > >> A package is just one of the artifacts that is stored in a git >> repository. Monticello packages have Monticello characteristics ... >> Cypress packages without Monticello meta data[1] are another package >> format and they have slightly different characteristics than Monticello >> packages and they are equally supported by tODE. [To be fair the Cypress >> package support is still experimental but a year ago I was doing active >> development using tODE and Cypress packages in conjunction with >> Monticello packages]. >> >> FileTree intentionally supports Monticello-style packages so that the >> FileTree packages can leverage the existing Monticello-based tools like >> Metacello (I had to extend Metacello to support Cypress-based packages) >> or the Monticello Browser. >> >> So at the end of the day, I think that git integration for Pharo depends >> upon a broader approach to integrating git-based tools throughout the >> tool eco-system. >> >> Once you start looking at a chunk of versioned disk as containing more >> than just Smalltalk source code there a numerous possibilities for >> building in-image tool support for distributing, sharing and maintaining >> documentation, workspaces, plugins, deployment scripts, etc. way beyond >> the limitations of a package ... > > Yes, this is it: that focus is interesting. That's why I refer to tODE when I > say you are showing us the way on git. But Pharo is a long way from being > that ambitious. > > Thierry > >
