> On 01 Dec 2014, at 21:48, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > Le 01/12/2014 21:04, Esteban Lorenzano a écrit : >> >>> On 01 Dec 2014, at 20:25, Dale Henrichs >>> <dale.henri...@gemtalksystems.com >>> <mailto:dale.henri...@gemtalksystems.com>> wrote: >>> >>> >>> >>> On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier >>> <thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>> 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:) >> >> he was, don’t worry :) > > Maybe I was :) > >> and as an aswer: yes, I’m not happy with filetree format, but I wouldn’t >> spend changing it until we have ready other parts of the tooling I think >> is necessary (using libgit2 instead osprocess for me is a must, while >> changing filetree format is just an enhancement) > > When I considered libgit2 a while ago, I was like you: a must. Then I saw > that: libgit2 was low-level => lot's of code in Pharo do do simple, basic > stuff. libgit2 required changes in NativeBoost => what, NativeBoost isn't > ready? Pharo is stuck in 32bits land=>No libgit2 by default on target OS. > NativeBoost is x86 only? No libgit2 on ARM.
I’m also concerned about that (32bits only). But we are already working on a solution. (and libgit2 support is already there, thanks to Max). as I said… our problem (not yours, but ours) is that we need to keep pharo independent of installed tools. So… libgit2. Otherwise I would be pushing gitfiletree a lot more loud :) Esteban > > In short: I don't have the resources to do that. It's too expensive for the > benefits. I'm impressed by Max and your dedication. > >> but… in the not so far future the metadata *needs* to change, I’m sorry. >> Merging in complex project (more than one developer, in fact) can become >> a pain if we do not improve that… even with mergetools from Thierry, is >> too complicated). > > The way you say it, I wonder if you understand what the MergeDriver is > supposed to solve (and what it isn't). You'll have to say more ;) > > (especially the bit about the merge of large projects/multiple developers > being too complicated...) > > Thierry > >> Esteban >> > >
