Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The ones marked with '.' do not appear in any of the branches,
but I am still holding onto them.

The topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

As we have already passed -rc3, things queued in 'next' let alone 'pu' are
unlikely to be merged to 'master' by the end of year unless otherwise
noted.

----------------------------------------------------------------
[New Topics]

* mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
 - gitweb: unify boolean feature subroutines

* cb/merge-recursive-fix (Mon Dec 15 02:41:24 2008 -0800) 3 commits
 - Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-
   recursive-fix
 - merge-recursive: do not clobber untracked working tree garbage
 - modify/delete conflict resolution overwrites untracked file

* cb/maint-merge-recursive-fix (Sun Dec 14 19:40:09 2008 -0800) 2 commits
 - merge-recursive: do not clobber untracked working tree garbage
 - modify/delete conflict resolution overwrites untracked file

* js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

* js/rebase-i-p (Mon Dec 15 11:05:31 2008 +0100) 2 commits
 - rebase -i -p: Fix --continue after a merge could not be redone
 - Show a failure of rebase -p if the merge had a conflict

I am undecided whether I should include these in 1.6.1 and have been
waiting for comments from Dscho.

----------------------------------------------------------------
[Post 1.6.1 items]

* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits
 + Add 'g' command to go to a hunk
 + Add subroutine to display one-line summary of hunks

* jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
 - gitweb: cache ...
[ message continues ]

There are a few issues to test and to resolve with Ajaxy blame
(blame_incremental):
 * does it work correctly with browsers other than Mozilla 1.17.2
   and Konqueror 3.5.3?
 * what gives better performance, and better visible performance
   on the client side: onreadystatechange or setInterval (and what
   interval)?
 * is it better to do more work on the server side, and for example
   send JSON with ready commits data; it is better to enable autoflush
   if sending raw "git blame --incremental" output?
 * the 'how long it took to generate page' patch should be decoupled,


I'd have to review resend series, but I think it would get Ack from


Uh?

-- 
Jakub Narebski
Poland
ShadeHawk on #git
--

[ message continues ]

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. So if nobody objects (and I think Dscho already said he was
going to be out of touch for two weeks due to the holidays) I'd like
this to remain in pu for the time being.

-Peff
--

[ message continues ]

Hi,


Could you be a bit more, like, specific, please?

Ciao,
Dscho

--

[ message continues ]

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

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.

-Peff
--

[ message continues ]

Hi,


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 

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

--

[ message continues ]

Right. I think core.notesref doesn't go far enough, because it doesn't
provide a way to talk about notes from two sources at the same time.
Like:



I agree that the data structure is sound, so I can probably work on top
of what you posted, too. I was planning on doing git-notes in C, though.

-Peff
--

[ message continues ]

Hi,


Ah.  That should be easy to do incrementally, by adding a ref_name 
parameter to the functions in notes.h, which can be NULL (falling back to 

Sure.  git-notes.sh is only in shell script to provide a proof-of-concept, 
and an example how to have an ultra-narrow "checkout" of the notes ref's 
tree.

Ciao,
Dscho

--

[ message continues ]