On Sun, 27 Jul 2008, Roman Zippel wrote: > 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: > > 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 -- 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
