On Mon, 28 Jul 2008, Roman Zippel wrote: > > Of course I did: > > $ git log --parents --name-only --full-history lib/vsprintf.c | grep -e ^commit | wc -l > 5929 > > This is same amount of commits as for gitk. OF COURSE it's the same numbr of commits. That's what gitk uses. That's what you *have* to use. You don't actually understand how git works, do you? > These are the same 20 commits (with parents) from a simple git-log. So what? The point I tried to make is that _any_ algorithm that gets the above case right by actually simplifying the commits "post facto" probably gets any case right. You tried to find some more interestign case, but you missed the whole point - even the "simple" case is quite hard enough. IOW, don't look for anythign more difficult, because if you do, you don't understand the problem to begin with! Do you not understand that the problem is that "post facto" isn't actually acceptable? Have you looked at all at the revision reading code? Hmm? The regular merge simplification does the simplification _before_ it has gathered the whole history of commits. And that is really really important. And I realize that you don't even seem to understand the difference. But to simplify it for you, let me give you a challenge. Try this: time sh -c "git log --parents --full-history lib/vsprintf.c | head" and if it takes noticeably more than a tenth of a second on my machine, you lose. Because that's roughly what it takes right now, and it's what means that effectively the normal log is instantaneous. It's why you can start looking at the log without waiting for three seconds, even though the _full_ log may take three seconds to compute (ok, on my machine it takes 2.3s, but whatever). And it's why gitk can start printing out the history _before_ three seconds has passed. And that's really really important. Try it. Really. Just do "gitk lib/vsprintf.c" and look at how it does things incrementally. It doesn't wait for a couple of seconds and then show things. Absolutely EVERYTHING in git would be totally trivial if you did it all based on generating first the whole history, and then simplifying it from there. But git would be unusably slow in real life, and it would scale _horribly_ badly with history size. So _all_ the normal code actually generates the history INCREMENTALLY, and it absolutely _has_ to work that way. 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
