2015-07-08 14:51 GMT+02:00 Alexandre Bergel <[email protected]>:

> 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 <[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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Reply via email to