git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Martin Langhoff <martin.langhoff@gmail.com>,
	Tim Harper <timcharper@gmail.com>,
	git@vger.kernel.org
Subject: Re: Bizarre missing changes (git bug?)
Date: Tue, 29 Jul 2008 17:32:33 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0807291716060.3334@nehalem.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0807291433430.6791@localhost.localdomain>



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@nehalem.linux-foundation.org>

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

  parent reply	other threads:[~2008-07-30  0:36 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-21 20:26 Bizarre missing changes (git bug?) Tim Harper
2008-07-21 20:37 ` Linus Torvalds
2008-07-21 22:53   ` Tim Harper
2008-07-21 22:55     ` Tim Harper
     [not found]   ` <8C23FB54-A28E-4294-ABEA-A5766200768B@gmail.com>
2008-07-21 22:57     ` Linus Torvalds
2008-07-26  3:12   ` Roman Zippel
2008-07-26 19:58     ` Linus Torvalds
2008-07-27 17:50       ` Roman Zippel
2008-07-27 18:47         ` Linus Torvalds
2008-07-27 23:14           ` Roman Zippel
2008-07-27 23:18             ` Linus Torvalds
2008-07-28  0:00               ` Roman Zippel
2008-07-28  5:00                 ` Linus Torvalds
2008-07-28  5:30                   ` Linus Torvalds
2008-07-29  2:59                   ` Roman Zippel
2008-07-29  3:15                     ` Martin Langhoff
2008-07-30  0:16                       ` Roman Zippel
2008-07-30  0:25                         ` Martin Langhoff
2008-07-30  0:32                         ` Linus Torvalds [this message]
2008-07-30  0:48                           ` Linus Torvalds
2008-07-30 23:56                             ` Junio C Hamano
2008-07-31  0:15                               ` Junio C Hamano
2008-07-31  0:30                               ` Linus Torvalds
2008-07-31  8:17                               ` [PATCH v2] revision traversal: show full history with merge simplification Junio C Hamano
2008-07-31  8:18                                 ` Junio C Hamano
2008-07-31 22:30                                   ` Linus Torvalds
2008-07-31 22:09                                 ` [PATCH v3-wip] " Junio C Hamano
2008-07-31 22:26                                   ` Linus Torvalds
2008-07-31 22:36                                     ` Junio C Hamano
2008-08-01  3:00                                     ` Junio C Hamano
2008-08-01  3:48                                       ` Linus Torvalds
2008-08-01  7:50                                         ` Junio C Hamano
2008-07-30  8:36                         ` Bizarre missing changes (git bug?) Jakub Narebski
2008-07-29  3:29                     ` Linus Torvalds
2008-07-29  3:33                       ` Linus Torvalds
2008-07-29 11:39                       ` Roman Zippel
2008-07-29 12:00                         ` David Kastrup
2008-07-29 15:50                         ` Linus Torvalds
2008-07-30  1:14                           ` Roman Zippel
2008-07-30  1:32                             ` Kevin Ballard
2008-07-30  1:49                             ` Linus Torvalds
2008-07-29  5:31                     ` Jeff King
2008-07-29 12:32                       ` Roman Zippel
2008-07-29 12:48                         ` Olivier Galibert
2008-07-29 12:52                         ` Jeff King
2008-07-29 17:25                           ` Linus Torvalds
2008-07-30  1:50                             ` Roman Zippel
2008-07-30  2:05                               ` Linus Torvalds
2008-07-30  4:26                             ` Jeff King
2008-07-30  4:52                               ` Linus Torvalds
2008-07-30  2:48                           ` Roman Zippel
2008-07-30  3:20                             ` Kevin Ballard
2008-07-30  3:21                             ` Linus Torvalds
2008-07-30  3:35                               ` Linus Torvalds
2008-07-30  4:23                             ` Jeff King
2008-07-27 23:25             ` Martin Langhoff
2008-07-28  1:29               ` Roman Zippel
2008-07-21 20:42 ` Alex Riesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.1.10.0807291716060.3334@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=martin.langhoff@gmail.com \
    --cc=timcharper@gmail.com \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).