From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)
Date: Sun, 26 Jul 2009 02:08:19 -0700 (PDT) [thread overview]
Message-ID: <m3ljmb3j7k.fsf@localhost.localdomain> (raw)
In-Reply-To: <7viqhfrfu5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ----------------------------------------------------------------
> [New Topics]
>
> * jk/show-tag (Sat Jul 18 06:14:37 2009 -0400) 2 commits
> + show: add space between multiple items
> + show: suppress extra newline when showing annotated tag
>
> Didn't look bad at all, but is not pressing either.
I like the output of "git show <tag>" much better than current one
(where I sometimes fall back on "git cat-file -p <tag>").
> * jn/gitweb-blame (Sat Jul 25 00:44:10 2009 +0200) 10 commits
> - gitweb: Create links leading to 'blame_incremental' using
> JavaScript
> - gitweb: Incremental blame (proof of concept)
> - gitweb: Add optional "time to generate page" info in footer
> - gitweb: Add -partial_query option to href() subroutine
This part (above) is RFC, especially the 'incremental blame' patch,
which is in flux.
Well, perhaps except 'time to generate page' (aka. 'timed' feature),
but even this still have some things (like name of feature enabling
this behavior: currently 'named', or unconditional requiring
Time::HiRes if it exists even if it is not needed).
> - gitweb: Use light/dark for class names also in 'blame' view
> - gitweb: Add author initials in 'blame' view, a la "git gui blame"
> - gitweb: Mark commits with no "previous" in 'blame' view
> - gitweb: Use "previous" header of git-blame -p in 'blame' view
> - gitweb: Mark boundary commits in 'blame' view
> - gitweb: Make .error style generic
>
> Still in flux/rfc.
This part is, I think, good now (after fixing embarassing but harmless
unquote_maybe() incident ;-)). Junio had some questions about style
used, but it can be very easily fiddled with later, IMVHO.
>
> * ns/init-mkdir (Sat Jul 25 06:59:28 2009 +0900) 1 commit
> + git init: optionally allow a directory argument
>
> Didn't look bad, but is not pressing either.
This is I think good UI improvement.
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2009-07-26 9:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-26 8:47 What's cooking in git.git (Jul 2009, #02; Sun, 26) Junio C Hamano
2009-07-26 9:08 ` Jakub Narebski [this message]
2009-07-26 10:32 ` en/fast-export, was " Johannes Schindelin
2009-07-26 10:35 ` db/transport-shim, " Johannes Schindelin
2009-07-26 14:08 ` Michael Haggerty
2009-07-26 17:27 ` gp/maint-rebase-p-onto, was " Johannes Schindelin
2009-07-26 17:28 ` Johannes Schindelin
2009-07-27 14:09 ` Alex Riesen
2009-07-28 7:27 ` Paolo Bonzini
2009-07-28 8:01 ` Junio C Hamano
2009-07-28 8:09 ` Paolo Bonzini
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=m3ljmb3j7k.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).