Re: Bizarre missing changes (git bug?)

On Tue, 29 Jul 2008, Jeff King wrote:

Jeff, it _is_ sane. When Roman says it's "incorrect", he is just wrong.

But it's true that "gitk kernel/printk.c" does simplify the history, and does so very aggressively. It does so very much by design, and has done it since pretty much day one. And it's a good thing - and it is "correct" - but it does mean that you may literally be missing things that are part of "history" but that didn't matter much.

The most trivial way to show this is actually by making such a simple case that it's obvious what is going on. Do this:

	mkdir test-simplification
	cd test-simplification
	git init
	echo "Hi there" > file
	git add file
	git commit -m"Initial file"

	git branch other-branch

	echo "Hello" > file
	git add file
	git commit -m"Modified file"

	git checkout other-branch

	echo "Hello" > file
	git add file
	git commit -m"Another person modified the file identically"

	echo "This is a stupid example" > another-file
	git add another-file
	git commit -m"Add another file"

	git merge master

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'[*]

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".

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.

And that's why "-full-history" and "git whatchanged" exist. They are ways to start delving deeper - they shouldn't be the _default_ mode, but they are ways to show more information when the initial default simple mode turns out to show that something didn't even matter for the end result.

And yes, there is a mid-way point between "aggressive simplification" (default) and "no simplification at all" (--full-history). It's more complex than either, and I do think it would be useful to have. It's what Roman wants, but as long as he thinks it's the _only_ correct answer, and refuses to face the performance issues, the discussion with Roman is kind of pointless.

			Linus

[*] when I say "_simplest_ history", I do want to point out that the history simplification is always a "local optimization", and it doesn't try to check all possible paths: there can be other histories that are even simpler on a global scale.

But in practice it is _one_ history of the file, and it's a history that is not "unnecessarily complicated" considering the simple heurstics for finding it.

So think "local minima" instead of "global minima", and in practice the local one is pretty close to the global one, although there are obviously always extreme cases where the two can differ by a whole lot.