> On 01 Dec 2014, at 19:11, Eliot Miranda <[email protected]> wrote: > > Hi Dale, > > On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs > <[email protected] <mailto:[email protected]>> > wrote: > Eliot, > > If we remove the meta data from the FileTree repo, then it will be necessary > to use the `adopt` command to restore the proper version history before > interchanging copying to an mcz repo or trying to merge with an mcz package > ... > > `adopt` is not an ideal solution, which is exactly why I've (stubbornly) > maintained the monticello meta data ... > > So *please* continue to be stubborn :-)
but this is a limitation of gitfiletree. real git integration (using libgit2) should be perfectly capable of reconstruct history without any metadata. also, in a point (not now, but eventually)… we will need to drop something. The idea of keeping anything ad eternum just does not scales. Esteban > > My statement about "as the community begins to use git-based repos as their > primary repository" includes a broad definition of community, in my mind:) > > +1 > > Cross-platform package portability has always been one of my primary concerns > and I do share your concern that it's a big step to remove the monticello > meta data from FileTree (again it's why I haven't done so yet) ... > > So far this is a bridge that doesn't need to be crossed, but when it becomes > time to cross it, there might be other options that can be applied (perhaps > an ancestry can be synthesized from the git meta data?) exactly. > > Which would be reasonable, but it needs to be there. And thanks. > > Dale > > > > > On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <[email protected] > <mailto:[email protected]>> wrote: > Hi Dale, > > On Nov 30, 2014, at 8:14 AM, Dale Henrichs <[email protected] > <mailto:[email protected]>> wrote: > >> >> >> On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <[email protected] >> <mailto:[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 ... > > Will that mean that packages will still be able to be interchanged with > Monticello? If yes, will that mean that packages will still be able to be > merged with Monticello? > >> Dale > > > > > -- > best, > Eliot
