Hi, On Tue, 29 Jul 2008, Linus Torvalds wrote: > Now, do these three things > > gitk > gitk file > gitk --full-history file > > and compare them. They all show _different_ histories. > > Which one is "correct"? They all are. It just depends on what you want to > see. > > The "gitk file" history is the simplest one BY FAR, because it has very > aggressively simplified history to the point where it tried to find the > _simplest_ history that explains the current contents of 'file'[*] It's "aggressively simplified" by not even bothering to look for more. "simplified" implies there is something more complex beforehand, but all it does is simple scan through the history as fast possible without bothering looking left or right. "simplified" implies to me it's something intentional, but this is more of an accidental optimization which happens to work in most situations and in the special cases it just picks a random change and hopes for the best. "git-log --full-history file" at least produces the full change history, but it has an performance impact and it doesn't produce a complete graph usable for graphical front ends. > >From a practical standpoint, and from having used this a long time, I'd > argue that the simple history is the one that you want 99.9% of all time. > But not _always_. Sometimes, the things that got simplified away actually > matter. It's rare, but it happens. > > For example, maybe you had a bug-fix that you _know_ you did, and it it > doesn't show up in the simplified history. That really pisses you off, and > it apparently really pisses Roman off that it can happen. But the fact is, > that still doesn't mean that the simple history is "wrong" or even > "incomplete". I gave more general examples. Tracking upstream source can produce this problem frequently. Another example are stable/unstable branches where the stable branch is occasionally merged into the unstable branch can produce this problem. > No, it's actually meaningful data in itself. If the bug-fix doesn't show > in the simplified history, then that simply means that the bug-fix was not > on a branch that could _possibly_ have mattered for the current contents. > > So once you are _aware_ of history simplification and are mentally able to > accept it, the fact that history got simplified is actually just another > tool. This is your _subjective_ interpretion of this problem, because it's not a problem for you, nobody else can possibly have this problem (or they just crazy). Even if I know about this limitation it still doesn't solve the problem, that _none_ of the graphical interfaces can show me a useful history graph of these situations. bye, Roman -- 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
