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 < [email protected]> wrote: > > > On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <[email protected]> > 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 >
