Re: Bizarre missing changes (git bug?)

On Wed, 30 Jul 2008, Roman Zippel wrote:

Umm.

Why would you? Yes, it's there, if you ask for --full-history. And no, I don't think --full-history is actually useful to humans - it's very much there as a "here's all the data" thing where you could have the tools post-process it, where often "post-processing" is actually just searching for it.

And no, it's not there if you don't use --full-history.

But now, instead of _complaining_ about this, I would suggest you think about why it's a _good_ thing, and why it's so useful?

In other words, you're arriving at all your complaints from the wrong angle entirely, and because you have convinced yourself that things have to work a certain way, and then you're upset when they don't.

But you should _unconvince_ yourself - and look at whether maybe all your initial preconceptions were perhaps totally wrong? Because they were.

The reason that commit 02630a12c7f72fa294981c8d86e38038781c25b7 doesn't show up in the normal log when looking at kernel/printk.c is that it really doesn't exist as a _relevant_ part of history for the current state of that file. It exists only as a a side-branch for the GFS2 quota code that first adds a line

	+EXPORT_SYMBOL_GPL(tty_write_message);

(in commit b346671fa196a), and then removes the line not long after (in that commit 02630a12c7f). And both of them go away (along with the whole side-branch), because they didn't end up mattering for the end result: they only ever existed in that side branch, and by the time it was merged back into the main branch, all changes had been undone.

In other words, that change - in a VERY REAL WAY - never actually mattered for the current state of kernel/printk.c. And the history simplification sees that, and avoids showing the whole pointless branch.

This is such an obviously _good_ thing that I really am surprised ay how you can continue to argue against it. Especially as the examples you give "for" your argument are so wonderful examples _against_ it.

And yes, you can actually force gitk to show the state of that commit and thus force it to acknowledge that that state was relevant (although you won't necessarily force it to acknowledge that the relevance ties together with the final end result). You do that by just telling it that you're not just interested in HEAD, but in that commit too.

So I would literally suggest that anybody interested in this subject really just do

	gitk kernel/printk.c &
	gitk HEAD 02630a12c7f72fa294981c8d86e38038781c25b7 kernel/printk.c &

in the kernel, and now compare the two side-by-side. Notice where they 
differ (hint: look for the commit a0f1ccfd8d37457a6d8a9e01acebeefcdfcc306e 
- "[PATCH] lockdep: do not recurse in printk" - which is in both, and look 
below it).

Now, which graph is the more relevant and understandable one from the standpoint of what the current state of kernel/printk.c is?

Honestly now, Roman.

Because if you were actually willing to see this as a _feature_ (which it very much is), you'd admit that it's a damn clever and useful one. But I suspect you have dug yourself so deep into a hole that you can't admit that even to yourself any more.

				Linus