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_r... 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.