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:

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

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

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

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html