On Sun, 10 Feb 2008, Jakub Narebski wrote: > > P.S. Would having generation + roots be enough? I'm wavering here. Maybe just "generation" works (the longest path from any root), because what we are looking for is essentially "guarantee that this commit cannot possibly be reached from that other commit", and I guess a simple generation count actually does work for that (if the generation of "x" is smaller than the generation of "y", we definitely cannot reach y from x). At the same time, I'm still not really convinced we need to add the redundant info. I do think I *should* have designed it that way to start with (and I thought so two years ago - blaah), so the strongest reason for "we should add generation numbers" at least for me is that I actually think it's a GoodThing(tm) to have. But adding it is a pretty invasive thing, and would force people to upgrade (it really isn't backwards compatible - old versions of git would immediately refuse to touch archives with even just a single top commit that has a generation number in it, unless we'd hide it at the end of the buffer and just uglify things in general). So even if it does work, the advantage isn't big enough for me to think it's really worth it. I'd *really* prefer to not have a flag day here, and the fact is, it's redundant information _and_ it fundamentally doesn't work with grafting anyway, so even if we were able to start from scratch, we'd then have to seriously consider dropping grafts. So let's work at not needing it, rather than argue whether we could use it or not ;) Linus - 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
