On Tue, Feb 10, 2009 at 01:59:06PM +0100, Johannes Schindelin wrote:

quoted text
> > 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.

OK. I think if you are seeing performance benefits from a 2-character
fanout, then we should standardize on that (do you have new performance
numbers somewhere?).

The notes implementation is now in master. If it's about to change in an
incompatible way, how do you want to handle it? I'm wary of a quick
patch to change the format this late in the release cycle. We could hold
it back from 1.6.2. Alternatively, we could let it release with a "this
is probably going to change" warning.

I think I favor holding it back, but I am not picky.

quoted text
> > 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.
> > [...]
> 
> You're correct.  This buys all kinds of trouble.

One other thing to note: I think we discussed in the past other kinds of
"more than one way to store it" strategies (e.g., letting a blob note be
the same as a tree note containing a blob "default"). They suffer from
some of the same issues (though not quite as badly, since you would at
least see that there was a conflict).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html