On Tue, Feb 2, 2016 at 11:38 AM, Dale Henrichs < dale.henri...@gemtalksystems.com> wrote:
> > > 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 ... 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? _,,,^..^,,,_ best, Eliot
