On Tue, Aug 28, 2007 at 10:15:01AM +0100, Johannes Schindelin wrote: > > +#define MAX_GENERATIONS 32 > > This is exactly what I tried to avoid, and why I did _not_ do the > "correct" fix. In some real-life (i.e. non-OpenSource) repositories you > do get a mess, and you do get quite a lot of messy merges. So I am not at > all convinced that this holds together in such setups. Yes, I considered making it dynamic, which would probably end up saving quite a bit of memory (since most commits use many fewer than 32) I think 32 is a reasonable limit in general, since at some point, do you really want to see that many merge traversals in the resulting name? > Besides, name-rev is already a memory hog. Your patch makes it worse. Let's say we allocate dynamically. The average per-commit number of stored merge traversals for linux-2.6 is 1.79. Each traversal is 5 bytes (though I think we could easily drop it to 3 or 4 -- do we expect generation counters larger 1.7 million?), for an average of 10 bytes stored per commit. Now compare that to the fact that we no longer need to strdup the tip_name. "tags/v2.6.22-rc1~1686^2~1" is _25_ bytes. So it's a net win (though not with a static array, obviously). > IOW I think that my patch is a good trade off between correct and working. I am all for making a trade-off if there is a reason. But if memory usage is your only concern, I think we can have our cake and eat it too. -Peff - 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
