Re: path limiting broken

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 16, 2006, 17:51 UTC
Message-ID: <Pine.LNX.4.64.0604161034290.3701@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.63.0604161905010.18184@wbgn013.biozentrum.uni-wuerzburg.de>

On Sun, 16 Apr 2006, Johannes Schindelin wrote:

Show 16 quoted lines

> 
> just to make it clearer what I want:
> 
> 	git-whatchanged -p next | grep parse_whatchanged
> 
> as well as
> 
> 	git log -p next | grep parse_whatchanged
> 
> do not find that any line like
> 
> 	int parse_whatchanged_opt(int ac, [...]
> 
> was removed, but they find that this line was added. However, in the 
> working tree (which has a fresh checkout of next), there is no such line 
> in log-tree.c. So I really would like to know where it vanished!

It was removed by merge 43f934aa: "Merge branch 'lt/logopt' into next".

The "parse_whatchanged_opt()" function never existed in that lt/logopt branch, and merging it (manually, I assume) it doesn't exist in the result either.

General hint: if you don't find it in "--cc", then that means that it's almost certainly a merge. "--cc" will only find things that _clash_, ie the end result is different from either of the branches (and in this case, it wasn't different, since parse_whatchanged_opt() simply didn't exist in the branch that was merged).

Now, finding things in merges can be a bit painful, but the sure-fire safe way is the old one: use "-m -p" to show _all_ sides of a merge as a diff. That's a really inconvenient format for reading, but it literally shows all changes to all parents.

Again, "git log log-tree.c" actually does do the right thing: the current state of "log-tree.c" really has _all_ of its history coming from the lt/logopt branch, which is why when you do

	git log -m -p log-tree.c | grep int parse_whatchanged_opt

you won't get any result at all: the _current_ state of log-tree.c really has no history what-so-ever that involved parse_whatchanged_opt. That may sound strange, but it really is very true. Doing a "gitk log-tree.c" shows what the real history of the contents of that file is.

And this actually comes back to a very fundamental git issue: git tracks _contents_. It doesn't care one whit if there was another branch that had some other history for that file: if that other branch didn't affect the contents of the file, then that other branch simply doesn't exist as far as that particular file history is concerned. It only exists as a "bigger" issue.

But that "-m -p" thing can be useful when you do want to see the bigger issue. As might "--no-prune-merges".

		Linus