> 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
~/HackathonSattose2015> git config --get merge.mcVersion.driver pathToGitFileTree-MergeDriver/merge --version %O %A %B > 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. Okay, but we all agree this is very far from an ideal solution right? Also, if I understand correctly, at each new repository I need to create a file .gitattributes : *.package/monticello.meta/version merge=mcVersion *.package/*.class/methodProperties.json merge=mcMethodProperties *.package/*.class/properties.json merge=mcProperties *.package/*.extension/methodProperties.json merge=mcMethodProperties *.package/*.extension/properties.json merge=mcProperties Alexandre > > > > On Jul 8, 2015, at 2:21 PM, Otto Behrens <[email protected]> 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 > > <[email protected]> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
