> On 28 Sep 2015, at 13:57, Ben Coman <[email protected]> wrote: > > On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier > <[email protected]> wrote: >> Le 28/09/2015 04:27, Ben Coman a écrit : >>> >>> >>> I have a vague recollection that the problem was a particular file >>> where data changed each commit and having the idea that this might be >>> solved by: each commit writing metadata to a different file e.g. >>> NNNN.metadata, and Monticello knows to pick up the highest numbered >>> metadata. >> >> >> Hum, I thought that as well, but in fact write the merge driver turned out >> as far better and simpler. Moreover, all type of data oriented files >> (ston, json, version) do not merge properly in git. So even Esteban saying >> he will use STON does not seems to solve the merge issue, unless he is >> planning something else. I do take in account we will have more metadata in >> the future, thanks to EPICEA, so we need a way to handle it. >> >> Merging is easy, you just need to hook into it. >> >> I believed also that we could do the merge ourselves and force git to commit >> the result, but discovered this was a bad idea. Imagine having to fire Pharo >> to merge a 250k OCaml project with 2k of st code in it :( > > btw, would "notes" [1] be useful for attaching metadata? > "A typical use of notes is to supplement a commit message without > changing the commit itself." > Or is the metadata better inside the commit?
Yes it could. I’ve been thinking about that too. There are some nice properties, e.g. 1 commit <-> one note (where a note can be tree). That way you don’t get merge conflicts on changing metadata. However, you’d need to find an equivalent mechanism for each new SCM. Also, using such a mechanism is a bit obscure. But the idea definitely deserves some attention. Cheers, Max > > [1] http://git-scm.com/docs/git-notes > > cheers -ben >
