On 01/30/2016 08:27 PM, Ben Coman wrote:
On Sun, Jan 31, 2016 at 3:38 AM, Dale Henrichs <dale.henrichs@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