[Pharo-dev] Support understanding changes

Stéphane Ducasse stephane.ducasse at inria.fr
Fri Nov 8 20:06:42 EST 2013

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

More information about the Pharo-dev mailing list