On 01/30/2016 08:27 PM, Ben Coman wrote:
On Sun, Jan 31, 2016 at 3:38 AM, Dale Henrichs
<dale.henri...@gemtalksystems.com> wrote:
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
What would it take to have the meta data spread out over multiple
lines (if that would work better with git?)
Hmmm I suppose that if the meta data were represented in STON (using
pretty print) the changes might be more mergable, but I think that
Thierry's algorithm might be still to a proper merge, since it takes
"object surgery" to get things right .... STON might make it possible
for a human to do the necessary edits though ...
Dale
