On Thu, 21 Jan 2010, Junio C Hamano wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > > > On Thu, 21 Jan 2010, Linus Torvalds wrote: > >> > >> We could fix it a few ways > >> > >> - ignore it. Most git programs will get the pack handling functions > >> anyway, since they want to get object reading. > > > > In fact, we should probably remove git-show-index. It may have some > > historical significance as a pack-file index debugger, but it has no > > actual redeeming features now, considering that the binary is a megabyte > > of useless crud with debugging info. > > > > However, we do actually use it in t/t5302-pack-index.sh. So in the > > meantime, how about this hacky patch to simply just avoid xmalloc, and > > separating out the trivial hex functions into "hex.o". > > > > This results in > > > > [torvalds@nehalem git]$ size git-show-index > > text data bss dec hex filename > > 222818 2276 112688 337782 52776 git-show-index (before) > > 5696 624 1264 7584 1da0 git-show-index (after) > > > > which is a whole lot better, no? > > > > (Or make it a built-in, if we actually think we want to carry it along in > > the long run) > > We tend to not remove things unless we are absolutely certain nobody uses > it, so probably making it built-in would be preferrable. I don't think > show-index is used very often if ever, but scripts that use hash-object > would use it really often and would do so via its --stdin interface if it > knows that it is creating more than a dozen objects, so start-up time > required to map the whole git is probably not an issue. I do use it, but for developing/debugging pack stuff. I don't suggest removing it, but I don't think making it a built-in has value either. So I really think that Linus' patch (which is missing hex.c btw) is a good thing to do, even if only for the cleanup value. Then, git-show-index could probably become test-show-index and no longer leave the build directory. Nicolas -- 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