On Mon, Sep 28, 2015 at 8:06 PM, Thierry Goubier
<[email protected]> wrote:
>
>
> 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
>>

All good questions I don't have answers for.  Its something I only
came across last week and I'm still understanding its general usage
pattern.
cheers -ben

Reply via email to