>> > > Indeed, some meta data is needed, although I think much of it can be properly > inferred if the commits have sufficient resolution.
no :) you do not what to infer refactoring. > As a side note, git for instance does not track renames: > > https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_renames.3F > http://permalink.gmane.org/gmane.comp.version-control.git/217 > Specially the last link is worth reading ;) > >> My approach would be to focus on tools in the Pharo world to explore that, >> at the Monticello GUI level (and merge tools). >> >> In the Git world, I'll focus simply on a file format able to store that >> knowledge, in a way which minimises git-induced conflicts... The goal being >> that a git merge would recreate a working Smalltalk result (no conflicts) >> with a correct EPICEA history (eventually recreated from the git stored >> data). >> >> What I know is that a single file in whatever format containing the EPICEA >> log will be a conflict magnet. > > If you attach the information to the commit itself that will be fine: > https://www.kernel.org/pub/software/scm/git/docs/git-notes.html > > because, as you say, each time metadata ends up in the sources part of the > git > repository we will have merge problems, since you can only properly merge such > data if you fully understand the semantic meaning. > > Additionally I think, that the transition data should not go into the sources, > technically they are no sources, but they belong on the commit itself. ok for now we hsould have a proto using MCZ and see how it goes.
