On 1/30/16 1:54 AM, Bernhard Pieber wrote:
Dale,
Thanks for your thorough answer. I really appreciate how you include links to
helpful articles.
I find the description of the workflow you actually use very enlightening.
However, one thing still remains unclear. In the last step, when merging the
pull request. How is the unchanged metadata reconciled with the code changes? I
just realized that I just don’t know what information is in the Monticello
metadata, which is not in the code?
Monticello metadata is basically the entire Monticello version history
of the package, it includes direct ancestors, commit comments, the GUID,
etc. For a FileTree repo, the meta data is stashed a separate file ...
The form of the data is actually serialized Smalltalk object graph - a
deeply nested set of Arrays - all written on a single line, so git has
very little chance of being able to merge two files ... The other bit of
Monticello metadata that is maintained by FileTree involves the per
method timestamp and developer initials - these are stored in a method
properties file associated with each class.
In fact is nearly impossible for a human to properly merge to Monticello
version histories, which is why Thierry Goubier's
GitFileTree-MergeDriver[1] is especially useful. Thierry's MergeDriver
fires up a Pharo image (called by git) and performs object surgery to
merge the conflicting version histories and method properties.
Anyway, in the scenario that I described, I simplified the process a bit
and left out some of the gorier details.
When I cherry-picked the commit for my topic branch and merged that
commit into Sven's latest master branch, the Monticello metadata was
certain to conflict, but when you perform a merge on a local git
repository and you've registered Thierry's merge driver with git, the
Monticello metadata is automatically merged.
I also made the assumption that Sven would not have made any additional
commits to his master branch between the time I merged his master branch
and the time I submitted the pull request - the latest version of a file
wins in a merge as long as they share the same immediate previous ancestor.
If Sven had made a new commit, the Monticello metadata would have
conflicted ...
For the record, these "guaranteed conflicts" are the only reason that
"removing Monticello metadata" enters into the conversation .... git
maintains it's own version history and method properties, so for
developers who are "exclusively using git" the Monticello metadata is an
annoying source of "meaningless conflicts." All of the information that
is present in Monticello meta data is present in git in another form
As I said, Thierry Goubier's magical GitFileTree-MergeDriver[1]
eliminates the conflict pain when the merges are performed in a local
git repository, but on GitHub, merging the Monticello metadata is a
constant thorn in one's side, since it becomes necessary to perform a
manual merge (and leverage Thierry's Merge Driver) when Monticello
metadata is involved.
Dale
[1] https://github.com/ThierryGoubier/GitFileTree-MergeDriver
