On Wed, 30 Jul 2008, Roman Zippel wrote: > > What the short simplified history is more pure laziness No. Roman, you're an idiot who doesn't even _understand_ what you are talking about. Sadly, you then _think_ you are so smart that you then refuse to even consider the fact that others disagree, so you don't even read what they write. Go to my previous email in this thread. Do the example. Look at the simplified version. Ponder. It's not "pure lazyness" when you get the simplified version. It's actually a MORE USEFUL RESULT! The simplified version shows the minimal explanation of how things ended up the way they are, and that is damn useful. What you want is extra _clutter_ most of the time. It's really sad how you cannot get over your own prejudices here. So Roman. Go back, read my previous email in this thread. It's message ID is <alpine.LFD.1.10.0807291006070.3334@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> in case it helps you find it. Read it twice, or three times. Read it with the notion that maybe you didn't know best after all. Read it with the possibility that maybe there are smarter people than you, and people who have actually worked with git for several years. And if you can't do that, at least stop cc'ing me with your idiocy. To get to the meat of your email: > The point I'm trying to make is that the compact history graph has the > potential to completely replace the simplified history. The only problem > is that it needs a bit of cached extra information, then it can be as fast > the short simplified history for the common case and it still can produce > as much information as the full simplified history, thus you can still > apply as much simplification as you want on top of it. You're simply full of sh*t. You make two huge mistakes, and I'll spend another few minutes of my life trying to educate you one final more time, even though from every single indication I have so far, you are unable to learn simply because you think you already know the answer. Your two mistakes are: - your "only" problem is fundamental. It's unsolvable. Git history simplification isn't per-file or even per-directory. It's per-any-random-set-of-pathnames. You can't "cache" the simplified information, and it's not "a bit" of cached extra info. It's fundamentally a metric truckload of info. With a cache, you can make the performance of a repeated query go fast, but that's totally uninteresting. - But the other huge mistake you make is EVEN MORE STUPID, because it's so ironic. That magical output you want, and claim is so perfect, and point out "thus you can still apply as much simplification as you want on top of it"? You know what? It already _exists_! It's exactly that --full-history case. Can you not see that? That's exactly that --full-history --parents cases. It gives you the full information. You can simplify it to what you want, exactly because it did _not_ simplify things for you. I've even told you so, multiple times, when I suggested you try to do that simplification in "gitk". In other words, git has the two cases you want: the "extreme simplified history" (that is nice to see what really _mattered_, with no extra unnecessary duplicate history that didn't actually affect the end result), and the "full" history (ooh, I know, we could make a command line called "--full-history" to get the latter, so that people who wanted to see it all and perhaps distill it to something else could do so). And I've told you over and over what you should look at, and I've told you over and over that the default is actually the _useful_ case, and why. But you seem to refuse to listen. You just close your ears and repeat your mantra, even though people smarter than you have told you why it's done the way it's done. Stop stuffing your ears. Listen to what people tell you. 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
