On Tue, May 27, 2014 at 1:19 PM, Esteban Lorenzano <[email protected]>wrote:
> > On 27 May 2014, at 17:09, [email protected] wrote: > > On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < > [email protected]> wrote: > >> >> 2014-05-27 20:41 GMT+02:00 Johan Brichau <[email protected]>: >> >>> Have you tried this? >>> >>> https://github.com/ThierryGoubier/GitFileTree-MergeDriver >>> >>> Not sure about the ^M problem though... >>> >>> Johan >>> >>> >> I second this, with GitFileTree it solves most problems of false >> conflicts caused by MC metadata. >> For true conflicts, I did not inquire. >> > > Ok, will have a look. > > At first sight, it looks scary and less friendly than a plain old MCZ > merge. > > But... git is the standard and it is painful to have to maintain things in > two places… > > > filetree format is buggy when merging. Reason is is keeping monticello > metadata and that does not plays very good with git (bah, it does not play > good at all). > Well intentionally buggy ... the only reason that the meta data is included in the filetree repo is to play nicely with Monticello - the metadata is required if one expects to copy mcz files into and out of filetree repositories ... it is possible to adopt mcz versions, biut I decided that I would be painfully backward compatible with monticello rather than deal with the chaos that would ensue if one were REQUIRED to adopt the correct versions ... When you yank the monticello meta data you have become committed to using the git repository and that can't be done until the level of tool support in the dev environement is up to snuff ... We are working (Max is doing some work there) in a better integration with > git, where we can drop all those metadata files and rely on git information > (it is there, we just need to use it). But as always, things needs time and > time is scarce :(. > > My recommendation in the mean time is to try gitfiletree. There is a good > chance that it fixes your problems. > Yep, Thierry has done some real good work! Dale
