ok Dale thanks for the explanation it makes things much clearer right now. I am glad it works well for you that means it will work well for me too and thus I am now much less reluctant to recommend it.��

Will give it a try and make a nice tutorial about it , together with gitfiletree.��

On Sun, Nov 30, 2014 at 6:14 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:


On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com> wrote:
��So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. ��


Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...

The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.

When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.��

I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...

As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...��

Dale