Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eric Wong <normalperson@xxxxxxxx> writes: > > > Sam Vilain <sam@xxxxxxxxxx> wrote: > >> This saves a bit of time when rebuilding the git-svn index. > > > > Does git-log still have the 16k buffer limit? If so then we can't use > > it because commit messages over 16k will be truncated and the git-svn-id > > line will not show up. Also, if that limit is removed I'd prefer to > > just add --pretty=raw to rev-list because git-log is stil porcelain and > > more likely to change. > > How about this? It passes the test suite, but other than that > hasn't seen much test yet. I tried to be careful, but sanity > checking by extra sets of eyeballs would be needed. The patch looks and runs alright to me, but then again I haven't looked at the C portions of git in a while :x I expected the malloc/free overhead to be much greater, but it's hardly noticeable (nor measureable with /usr/bin/time or bash built-in time). There are just a handful more pagefaults measured with /usr/bin/time, but the runtime performance is neck-and-neck with/without the patch. Maybe glibc (2.3.6 on x86 Debian Etch) and Linux (2.6.18) are just doing a very good job with memory allocation... I wonder how well it runs on other platforms. -- Eric Wong - 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
