From: Chris Shoemaker <c.shoemaker@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
Date: Thu, 27 Oct 2005 20:50:29 -0400 [thread overview]
Message-ID: <20051028005029.GA2654@pe.Belkin> (raw)
In-Reply-To: <Pine.LNX.4.64.0510271709120.4664@g5.osdl.org>
On Thu, Oct 27, 2005 at 05:12:33PM -0700, Linus Torvalds wrote:
> Add the "-r" flag to do the recursive thing, ie
>
> git-diff-tree -r --name-only
>
> should do the right thing.
Ah, yes, it does. Thanks.
> > True. Maybe gitk and gitweb can share a cache containing the tree
> > diffs. Or maybe git-core can cache tree diffs?
>
> Creating them is fast enough if there is no IO. Make sure your project is
> packed, and you should be ok.
>
> The expensive part is the "-p" thing to create patches. If you avoid the
> patch creation, you should be ok.
git-diff-tree -r --name-only is pretty quick and it actually does a
halfway reasonable job of representing damage-potential.
> > But, in general, is there interest in a visual indicator of commit
> > size and/or type in gitweb?
>
> I kind of like it, but I'm not sure how useful it is, and maybe it does
> really want the whole patch size (not just how many files it touches).
Hard to say. Neither one is going to be perfect, so I'm ok with
settling for the cheap one if it's halfway reasonable. I think I'll
mock up the merge indicator and see if there's any value added there.
So, what's the best way to detect merges? Maybe see if
'git-cat-file commit $hash | grep ^parent | wc -l' is greater than 1?
> That's where caching might save your *ss.
Ok, but that cache would live inside GIT_DIR an be shared with gitk,
right?
-chris
next prev parent reply other threads:[~2005-10-28 0:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-27 20:39 [PATCH gitweb] Visually indicating patch size with horizontal bars Chris Shoemaker
2005-10-27 22:02 ` Junio C Hamano
2005-10-27 23:48 ` Chris Shoemaker
2005-10-28 0:12 ` Linus Torvalds
2005-10-28 0:50 ` Chris Shoemaker [this message]
2005-10-28 1:08 ` Martin Langhoff
2005-10-28 1:13 ` H. Peter Anvin
2005-10-28 8:29 ` Andreas Ericsson
2005-10-28 9:31 ` Junio C Hamano
2005-10-28 1:16 ` Martin Langhoff
2005-10-28 2:38 ` Linus Torvalds
2005-10-28 3:52 ` Junio C Hamano
2005-10-28 16:02 ` Linus Torvalds
2005-10-28 1:56 ` Kay Sievers
2005-10-28 2:38 ` Chris Shoemaker
2005-11-01 23:30 ` Petr Baudis
2005-11-01 23:33 ` Martin Langhoff
2005-11-01 23:43 ` Petr Baudis
2005-11-02 8:08 ` Andreas Ericsson
2005-11-02 10:37 ` Johannes Schindelin
2005-11-02 12:19 ` Andreas Ericsson
2005-11-02 12:43 ` Johannes Schindelin
2005-11-02 0:12 ` Chris Shoemaker
2005-11-02 0:26 ` Kay Sievers
2005-12-05 0:04 ` Petr Baudis
2005-12-05 1:03 ` Chris Shoemaker
2005-10-28 9:16 ` Josef Weidendorfer
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=20051028005029.GA2654@pe.Belkin \
--to=c.shoemaker@cox.net \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=torvalds@osdl.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 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).