2015-09-28 13:57 GMT+02:00 Ben Coman <[email protected]>: > 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? >
I don't know. What happens to notes when you merge? Do you need to fetch down all the ancestors (some of them without notes, because it was a merge of whatever external stuff was in the repository, so you need to recurse[2]) and merge them yourself everytime? What happens if a guy do a by hand edit of a st file and commits outside of Pharo? Can it work outside git (Fossil, Mercury, bazaar)? Does it scale to a lot of metadata? Thierry [2] gitfiletree has that code, and it gives unintuitive, but correct, results at time. > [1] http://git-scm.com/docs/git-notes > > cheers -ben > >
