Re: RFC: Flat directory for notes, or fan-out? Both!

> On Mon, Feb 09, 2009 at 10:12:06PM +0100, Johannes Schindelin wrote:
> 
> > Shawn triggered some well needed thinking on my part about the notes 
> > implementation.  At the moment, we have flat directory structure, and read 
> > all of them in one go (when needed).
> > 
> > I think we should support that, because it is relatively easy to generate 
> > that kind of trees for small-scale applications.
> 
> Hmm. Do we really care about how easy it is to generate? Are we
> expecting people to not use the command interface and instead check out
> a notes tree and start putting stuff into $commit/foo?

> And if we are encouraging the dual possibilities, how do we handle the 
> case of merging two trees with equivalent but differently-formatted 
> content?
> 
> Imagine I have three users, A, B, and C, all collaborating on a project
> with notes. A and B use the "git notes" interface which generates a
> fan-out directory structure. C uses his own script that directly writes
> to the notes tree without fan-out.
> 
> Now let's imagine A, B, and C all write a note for commit X, and A pulls
> from the other two. When he pulls from B, there is a file-level
> conflict, and he decides that his note is better and resolves in his
> favor. But when he pulls from C, there is _no_ conflict, and now there
> are two notes for the same commit in his notes tree. You can give the
> multiple notes some sane semantics (one trumps the other, or they are a
> list, or whatever), but there is still an inconsistency: B's notes and
> C's notes behave differently. So now A has to start caring about how
> other people generate their notes.
> 
> The only two solutions I can think of are:
> 
>   - when A pulls notes, he does a specialized merge that normalizes the
>     note trees
> 
>   - particular notes trees are specified as being in "fan out" or "not
>     fan out" mode. But there is no place to specify that to enforce it.