Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
- From
- Chris Shoemaker <c.shoemaker@cox.net>
- Date
- Oct 28, 2005, 00:50 UTC
- Message-ID
- <20051028005029.GA2654@pe.Belkin>
- 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:
Show 5 quoted lines
> 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.
Show 8 quoted lines
> > 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.
Show 5 quoted lines
> > 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