Re: Bizarre missing changes (git bug?)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 27, 2008, 18:47 UTC
Message-ID: <alpine.LFD.1.10.0807271144520.3486@nehalem.linux-foundation.org>
In-Reply-To: <Pine.LNX.4.64.0807270049290.6791@localhost.localdomain>

On Sun, 27 Jul 2008, Roman Zippel wrote:

Show 10 quoted lines

> Hi,
> 
> On Sat, 26 Jul 2008, Linus Torvalds wrote:
> 
> > > Is there a way to change that default?
> > 
> > Use an alias or something.
> 
> This doesn't help with the graphical front ends and they only use what git 
> gives them.

And the graphical front-ends is exactly why --full-history cannot be the default.

We _could_ make it the default for non-graphical ones, if we also say "--no-merges". But then:

Show 16 quoted lines

> > To see why it's the default, do a few tests. In particular, try it with 
> > gitk on the kernel. Try it on some fairly simple file that doesn't get a 
> > lot of churn. Example:
> > 
> > 	gitk lib/vsprintf.c
> > 
> > vs
> > 
> > 	gitk --full-history lib/vsprintf.c
> > 
> > and if you don't _immediately_ see why --full-history isn't the default, 
> > there's likely something wrong with you. One is useful. The other is not.
> > 
> > So we absolutely _have_ to simplify merges. There is no question about it.
> 
> Well, I don't want that much history.

Right. Nobody does.

> Let's take a different example.

No, let's not.

Unless you can solve that _one_ example efficiently, nothing else matters.

The above example is all you ever need. Make that one work right (and efficiently), and everything is fine.

And no, some random ruby code doesn't make any difference what-so-ever. There are efficiency constraints here that make any ruby solution be unrealistic to begin with.

			Linus