Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 23, 2008, 16:52 UTC
Message-ID: <alpine.DEB.1.00.0812231746250.30769@pacific.mpi-cbg.de>
In-Reply-To: <20081223163811.GA25658@coredump.intra.peff.net>

Hi,

On Tue, 23 Dec 2008, Jeff King wrote:

Show 12 quoted lines

> On Tue, Dec 23, 2008 at 05:26:01PM +0100, Johannes Schindelin wrote:
> 
> > > I haven't had much time to really look at this closely, and I probably 
> > > won't for another week or so due to the holidays. But from my cursory 
> > > examination, I think I want to propose something that is a bit 
> > > different.
> > 
> > Could you be a bit more, like, specific, please?
> 
> The way that GIT_NOTES_REF and core.notesref work aren't what I had in 
> mind. I imagined something more amenable to having lots of different 
> metadata notes.  Refer to the other messages I have written on "naming".

Unfortunately, there were way too many messages between you and Govind, with not enough new stuff that could interest me, so I had to stop reading them to avoid depleting my Git time budget each and every single day.

However, note that without something like core.notesref you will never be able to have private and public notes.

And I very much want to have private notes _and_ public notes on the very same commits of the very same branches.

Show 8 quoted lines

> I don't want to hold up progress, so if people want those patches in 
> "next", then go for it. What I really meant by my email was that I think 
> my suggested changes might be simpler to see as a re-roll rather than 
> patches on top, but since I can't work on them for a while, I didn't 
> want Junio to take silence as "OK, nobody has complained, so it's time 
> for this to graduate to next." But again, if people are ready to start 
> playing with this and building on top of it, then I don't want to stand 
> in the way.

I just wanted to fiddle a little bit with profiling, as I really do not understand why the new notes perform that badly against the old notes, even allowing for reading a complete, possibly huge tree into a hashmap.

And while I am almost sure that there is a stupid bug lurking that will kick the performance again, I think the basic design is sound, and it should be easy to modify no matter which way you want to change the behavior with regards to trees/blobs or refs.

Of course, I'd like Miklos' read-tree bug solved before any more work is done on notes, since we are in -rc4 after all, and that is a potentially pretty serious bug.

Ciao, Dscho