On 28 Sep 2015, at 13:57, Ben Coman <btc@openinworld.com> wrote:
On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier <thierry.goubier@gmail.com> 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