> On 13 May 2017, at 15:51, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > Le 13/05/2017 à 15:43, Esteban Lorenzano a écrit : >> >> >>> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymc...@me.com> >>> wrote: >>> >>> I’m not a bit expert, but if you don’t use “metadataless” format >>> everything works fine with monticello. I.e. each git commit >>> contains all the mc history. >> >> yes, but with iceberg we did another choice: we force metadataless >> and do not keep compatibility with monticello. this is like that by >> design: keeping the metadata was too much noise and generated a lot >> of conflicts we don’t want. > > The metadata-less format was experimented with before Iceberg because we knew > that recreation of MC-compatible metadata out of the vcs log was already > working. > > Then FileTree (and MC) was modified to make sure that the metadata-less > format would be compatible with MC. > > Now, Iceberg has decided to be non-compatible with MC. But this has nothing > to do with the underlying format.
Iceberg uses filetree metadataless as file format (it uses even the same class to do the write) so what you are saying is not true ;) What changes is that instead adding a random cypress.1 we add the a number which is a timestamp of the commit. > >> So, using iceberg is not using git as “just another repository format >> as http, ftp, etc.”. If you want to keep both versions, then you >> need to save in mc format then save again in iceberg (or viceversa). > > Which looks clumsy at best and at worse, will make the transition to Iceberg > a pain. I disagree. the cost of keeping eternal backward compatibility is not moving forward. And Peter did a very good tool to easy migrations that respect history. Also, nobody is forced to use iceberg: you don’t want it, do not use it. You still have monticello. > > Thierry > >> Esteban >> >>> >>> Uko >>> >>>> On 13 May 2017, at 09:28, Thierry Goubier >>>> <thierry.goub...@gmail.com> wrote: >>>> >>>> Le 13/05/2017 à 08:58, Stephane Ducasse a écrit : >>>>> My gut feeling is that it will be better not to mix git and >>>>> MC. >>>> >>>> It is easy to make MC compatible with Git. >>>> >>>> It wasn't that hard in the past, but needed a community effort >>>> (MC being a core part of the system). Now, with the >>>> infrastructure underway (libgit, git fast-import) it looks very >>>> easy to implement. >>>> >>>> Thierry >>>> >>>>> >>>>> >>>>> On Fri, May 12, 2017 at 11:09 PM, Oleksandr Zaytsev >>>>> <olk.zayt...@gmail.com <mailto:olk.zayt...@gmail.com>> wrote: >>>>> >>>>> Hello >>>>> >>>>> Two days ago I was trying to send the slice with my fix to >>>>> PolyMath using Monticello. But the version number got set to >>>>> 1494471195. Today I realized that all the packages to which I >>>>> commit are numbered like that. >>>>> >>>>> Cyril Ferlicot explained to me that this happens when I mix git >>>>> and Monticello commits. He suggested that I use a separate >>>>> image for committing to GitHub, or file out/file in if there is >>>>> a lot of changes to commit. >>>>> >>>>> Can this be considered a bug? Should I report it? >>>>> >>>>> I think it would be causing problems for many people. >>>>> >>>>> Oleks >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > >
