On Tue, Feb 10, 2009 at 01:59:06PM +0100, Johannes Schindelin wrote: > > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
