Hi, On Sun, 20 Aug 2006, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Sun, 20 Aug 2006, Rutger Nijlunsing wrote: > > > >> 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. > > I do not speak ruby (well I suspect I could read it if I wanted > to but I didn't try) so this may or may not be something > Johannes inherited from the original, No, it was no rewrite. But looking at the Ruby code again, it is not really similar: the builtin uses the hash to cache the sizes even for a blob. Further, it does not unpack the objects (except for the trees, and for the revision walk if you limit by pathname). However, it inherits this: > but I think the code overcounts blobs and trees for a top-level tree > that happens to have the same blob (or tree) twice. I am not sure if > that is intended. > > Overcounting would give closer estimate for how big a tar > archive would be, or how big an populated working tree would be, > so it could be considered a feature. It all depends on what > this tools is useful for, I guess. I dunno. No idea what the original requester wanted to do with it. For me, it was a nice distraction from my work. And a nice occasion to finally copy^H^H^H^Himplement the independent hash map code I always wanted to refactor from object.c. And a nice demonstration how easy it actually is these days to implement a builtin. Ciao, Dscho - 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