Le 02/02/2016 21:56, Eliot Miranda a écrit :
On Tue, Feb 2, 2016 at 11:38 AM, Dale Henrichs <[email protected] <mailto:[email protected]>> wrote: On 01/30/2016 08:27 PM, Ben Coman wrote: On Sun, Jan 31, 2016 at 3:38 AM, Dale Henrichs <[email protected] <mailto:[email protected]>> 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 ... Please tell me this isn't about line endings? Why can't the version history be written with lf line endings? That's hardly a bone of contention is it?
No, it's a lot more complex than that. It's simply hard to do a merge-able text log format. Git also makes a mess of json / ston files, simply because they are structured data in what appears to be text files, git treat them as text files, and three-way line by line merging does not work.
The only hope you can have is to make a format which is easier for a human to correct when git creates a conflict when merging ... in short, something which would only make it easier as long as the history is limited to 50 versions and a single developper :(
Now, given how much cleaner, safer and sound is extracting that data from the dvcs log, I'll never bother with that sort of things again.
Thierry
