From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Johannes Sixt <j6t@kdbg.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
"Simon Schubert" <corecode@fs.ei.tum.de>
Subject: Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)
Date: Sun, 21 Dec 2008 11:03:42 -0800 (PST) [thread overview]
Message-ID: <m363ldcpv9.fsf@localhost.localdomain> (raw)
In-Reply-To: <7vr641pvid.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ----------------------------------------------------------------
> [New Topics]
>
> * mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
> - gitweb: unify boolean feature subroutines
The last version, I assume? IMHO it is a good change.
> * 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
Nice to see it resurrected.
> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
> - gitweb: cache $parent_commit info in git_blame()
> - gitweb: A bit of code cleanup in git_blame()
> - gitweb: Move 'lineno' id from link to row element in git_blame
>
> I've briefly looked at the resurrection of Ajaxy blame that comes on top
> of this series and it looked promising.
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,
improved, and send separately...
> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
> - gitweb: Optional grouping of projects by category
> - gitweb: Split git_project_list_body in two functions
> - gitweb: Modularized git_get_project_description to be more generic
I think it is not yet finished, but it looks nice.
> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
> - gitweb: link to patch(es) view in commit(diff) and (short)log view
> - gitweb: add patches view
> - gitweb: change call pattern for git_commitdiff
> - gitweb: add patch view
>
> Updated series.
I'd have to review resend series, but I think it would get Ack from
me.
> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
> * nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
> * jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
> * jc/clone-symref (Sat Nov 29 23:38:21 2008 -0800) 6 commits
Those are interesting...
> * jc/apply (Sun Sep 7 14:36:24 2008 -0700) 1 commit
> . WIP
Uh?
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2008-12-21 19:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-21 12:23 What's cooking in git.git (Dec 2008, #03; Sun, 21) Junio C Hamano
2008-12-21 19:03 ` Jakub Narebski [this message]
2008-12-23 12:05 ` Jeff King
2008-12-23 16:26 ` Johannes Schindelin
2008-12-23 16:38 ` Jeff King
2008-12-23 16:52 ` Johannes Schindelin
2008-12-23 17:34 ` Jeff King
2008-12-24 11:55 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m363ldcpv9.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=corecode@fs.ei.tum.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.