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.
-Peff
--
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
