Hi, On Tue, 10 Feb 2009, Jeff King wrote: > 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? I wanted to be nice to existing users of the feature (it is in 'next', after all, and Thomas has produced some awesome examples, that will hopefully show the scalability of the thing). But you're right, it almost, but not quite, too late to switch. > 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. You're correct. This buys all kinds of trouble. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
