Hi, [Junio: seems like both Peff and me would like to hold the notes out of 1.6.2, would you mind?] On Tue, 10 Feb 2009, Jeff King wrote: > 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 thing is: Shawn is correct when he says that a tree object to hold the notes of all commits (which is not an unlikely scenario if you are thinking about corporate processes) would be huge. > 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. Yes, I am also in favor of holding it back. > > > 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). Actually, I do not see much of a problem there. If the entry (corresponding to the commit name) in the notes tree points to a blob, then that is that, if it points to a tree, then we just read all of the objects therein (or maybe at a later stage we allow restricting to a certain file basename). The point you raised earlier, that there would be a lot of ambiguity if we allow both flat and fan-out directory structures, is a valid point, though. 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
