2015-07-08 14:51 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:
This is frustrating���.

I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver
And I got:

~/HackathonSattose2015> git merge master
pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory
fatal: Failed to execute internal merge

Looks like a problem when installing the merge driver.

pathToGitFileTree-MergeDriver shoudl not appear like that, so it seems the make used to install wasn't successful. Can you show the result of

$��git config --get merge.mcVersion.driver
��

Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missing���.

FileTree is a standardised format, cross-smalltalk compatible, browsable on github, with a nice set of tests to make sure it keeps working across many revisions of Squeak, Gemstone and Pharo.

Maybe I will go back to Smalltalkhub afterall���

Up to you ;)

Thierry
��

Alexandre


> On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto@finworks.biz> wrote:
>
> We have a .gitignore file that contains:
> version
> methodProperties.json
>
> So, we don't bother.
>
> The side effects of this are:
> Without methodProperties.json, you have the default author and
> meaningless timestamp.
> Without the version file, loading does not work properly. So we have a
> script that generates version files for each package before we load
> into the image. At first, this script counted versions for the package
> and got all the info from the git repository. But this was too
> expensive (because the file system became slow when traversing the git
> repo to find the meta data). So now, we just generate a version file
> with a fixed author, date & time now and a UUID & version number
> derived from the SHA1 of the .package directory.
>
> We get all the meta-information directly from the git repo, using git
> tools. This can be better with GitFileTree.
>
> So we really just use basics of Monticello & Metacello and do the rest
> externally from the image. We need to explore the available tools
> more.
>
> On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel
> <alexandre.bergel@me.com> wrote:
>> Hi!
>>
>> Do I still need to press the merge button in Monticello when I am working on a filtree git repository?
>> I understand that no since the merging has to be done by Git, and not by monticello.
>>
>> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example:
>>
>> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version
>> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json
>> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json
>>
>> Why do we need this methodProperties.json and version files? Shouldn���t git handle this?
>>
>> How should I merge these files? Any experience?
>>
>> Cheers,
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel�� http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>

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