Thread (45 messages) flat view 45 messages, 10 authors, 2016-06-15

Re: Bizarre missing changes (git bug?)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:45:03


On Sun, 27 Jul 2008, Roman Zippel wrote:
Hi,

On Sat, 26 Jul 2008, Linus Torvalds wrote:
quoted
quoted
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:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help