On Tue, Aug 28, 2007 at 10:15:01AM +0100, Johannes Schindelin wrote:

quoted text
> > +#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?

quoted text
> 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).

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html