Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)
From: Jakub Narebski <hidden>
Date: 2016-06-15 22:48:06
On Mon, 25 Jan 2010 at 16:21:51 -0800 (PST), J.H. wrote:
quoted
I am waiting for response from (I guess busy) J.H.; I can do the re-roll if he is too busy to work on it.I'm juggling about 4 things in the air right now, with gitweb being one of them, and two of them involving external entities to kernel.org. It's good news all told, just requires a fair amount of my time (currently) and babysitting. I've been digging through the patches you've got right now. I should really just pull them in from your git tree again.
Note however that my series (gitweb/cache-kernel branch) is based on gitweb-ml-v2, not on newer gitweb-ml-v5.
After reading through some of the discussions today I've had some more ideas on the caching stuff, they are written up on my whiteboard and I might be able to get to shortly, but I've got a rather large wall looming ahead of me that's going to chew up a *LOT* (read at least a month, if not two) of my time, so I'm a bit under the gun to try and get this as far as I can before I hit that wall or this is going to fall by the wayside again till I've got time again.
I think the best way of utilizing your time would be for you to take active part in discussion, especially in what git.kernel.org needs and why. I can clean up the miscellaneous improvements parts myself, and re-roll caching patches.
quoted
quoted
For the main caching patch, it seems like good idea to take Jakub's split-up series instead, let's see what is J.H.'s opinion on the series?Let me at least make them into proper patches, with commit messages and configureability at least of the original caching patch by J.H. Also the question whether to create 'print -> print $out' patch, or to manipulate *STDOUT instead must be solved, I think, before applying those patches... well, at least beyond 'pu'. I am waiting for promised J.H. comments, when he will have time for it...
-- Jakub Narebski Poland