Thread (8 messages) flat view 8 messages, 4 authors, 2016-06-15

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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:45:49

Hi,

On Tue, 23 Dec 2008, Jeff King wrote:
On Tue, Dec 23, 2008 at 05:26:01PM +0100, Johannes Schindelin wrote:
quoted
quoted
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help