Re: [ANNOUNCE] git-rev-size: calculate sizes of repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sun, 20 Aug 2006, Rutger Nijlunsing wrote:

> On Sun, Aug 20, 2006 at 06:09:34PM +0200, Johannes Schindelin wrote:
> > Hi,
> > 
> > On Sun, 20 Aug 2006, Rutger Nijlunsing wrote:
> > 
> > > On Sun, Aug 20, 2006 at 03:20:19PM +0200, Johannes Schindelin wrote:
> > > > Hi,
> > > > 
> > > > On Sun, 20 Aug 2006, Rutger Nijlunsing wrote:
> > > > 
> > > > > You can also find it on http://www.wingding.demon.nl/git-rev-size.rb
> > > > 
> > > > Ruby is _so_ mainstream. Could I have a Haskell version, pretty please?
> > > 
> > > I _knew_ it... Please go bug someone else. The only thing I did was
> > > help someone, and for that I choose my own tools since I do it for
> > > fun.
> > 
> > Fair enough.
> > 
> > -- 8< --
> > [PATCH] Add git-rev-size
> > 
> > This tool spits out the number of trees, the number of blobs, and the total
> > bytes of the blobs for a given rev range.
> > 
> > Most notably, it adds an object hash map structure to the library.
> > 
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
> 
> 
> [Hm, the itch seems to be contagious. Better watch out...]
> 
> Small comments:
> 
> The 'git-rev-size' name was chosen because originally it understood
> the same arguments as git-rev-list. You might want to add this popen()
> back, or have some other way to share those (might be simple in C). Or
> is setup_revisions() enough to have the power of git-rev-list?

It is enough. That is the beauty of setup_revisions().

> If seperate commits have to be given on the command line instead of a
> range, the command line limit is hit quite quickly (~780 commits). And
> if you'll be using xargs, the hash / cache will be less of an advantage.

Certainly. But I doubt that you'll use this command all that often. 
However, it was a nice example of how easy it is to write a git builtin ;-)

> The original request was 'for each commit' to get an idea of the size
> growth during a project.

Since the arguments are the same as for git-rev-list, this is easy enough.

> 'builtin_rev_size_usage' is not referred to in the patch, only defined.

True.

-- 8< --
[PATCH] rev-size: actually show usage

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
---
 builtin-rev-size.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/builtin-rev-size.c b/builtin-rev-size.c
index ad88e48..184f926 100644
--- a/builtin-rev-size.c
+++ b/builtin-rev-size.c
@@ -78,6 +78,9 @@ int cmd_rev_size(int argc, const char **
 	revs.commit_format = CMIT_FMT_UNSPECIFIED;
 	argc = setup_revisions(argc, argv, &revs, NULL);
 
+	if (revs.pending.nr == 0)
+		usage(builtin_rev_size_usage);
+
 	prepare_revision_walk(&revs);
 
 	while ((commit = get_revision(&revs))) {
-- 
1.4.2.ga5e8f-dirty

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]