Our âcodingâ atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class. Now⦠you are complaining in the wrong problem. FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. Thatâs what is plain wrong and should be at least optional :) I would happily integrate a âPlainFileTreeâ protocol (without monticello information) as an option, if someone provides such extension. Crap, I could make it myself if I have the time!⦠maybe next insomnia night :P Esteban
On 08 Jul 2015, at 14:51, Alexandre Bergel <alexandre.bergel@me.com> wrote:
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
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â¦.
Maybe I will go back to Smalltalkhub afterallâ¦
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.