Re: Merge with git-pasky II.

On Fri, 15 Apr 2005, David Woodhouse wrote:

Read my email about finding "what changed" that I sent out a minute ago.

I claim that my algorithm for finding "what changed" handles your "single file" case as a very small (and usually quite uninteresting) special case.

I claim (and if you just look at my proposal I think you'll agree) that I can track single functions, and do it efficiently. WITHOUT adding any meta-data at all.

The thing is, if the question is "I have this piece of code, and I want to see what changed", you fundamentally _can_ do that efficiently. That's really what git was designed for. It's the whole _point_ of having history in the first place. If git didn't care, it wouldn't have a back-pointer to the tree it came from, and we'd all be just merging pure trees.

But you mix that question up with "how do I save that information in the commit", which is a totally unnecessary mix-up, and which makes things MUCH more complicated, for absolutely zero gain.

In fact, because you mixed up those two issues, the problem now became so complicated that you can no longer solve it, so you start doing hacks like "the user has to tell us what he did" (aka "bk mv" or "svn rename"), and you start mentally to limit yourself to files, because you realize that you _have_ to limit your intractable problem to make it at all solvable.

And I'm telling you that your problem is STUPID. You made it stupid by thinking that every question about the source tree should be answered at commit time. Which just clearly isn't true!

If you just drop the tying-together, and accept that "what changed" is a valid question _regardless_ of trying to track it at commit time, now your whole world opens up. Birds sing, the sun is shining on you, and beautiful scantily clad women (or men) dance around you. The world is suddenly a good place, just _filled_ with possibilities.

Suddenly you realize that if the question is just "what changed in this piece of code" (and let's face it, that _is_ the question), you can track it afterwards. Trying to tie in "commit time" into the question was what made it hard. If you do _not_ due that (totally unnecessary) tie-in, the question suddenly becomes easy to answer, and several obvious and simple answers spring to mind pretty immediately.

No. Git absolutely does have everything you need already. You just aren't realizing that it's already there - in the data - and that you can do much more intelligent searches for changes if you accept that undeniable fact.

The fact that you can NOT do those searches at commit-time (which is a global op), and can only do them if you have a specific question in mind ("what changed _here_"), is the big issue.

The thing is, at commit-time you'd need to answer every possible question ("what changed here, and here, and here, and in this function, and in this file, and in this directory and why did this identifier get renamed and why is the sky blue"). AND YOU FUNDAMENTALLY CANNOT DO THAT. It's impossible.

But once you _know_ the question (which is the only time when the answer is actually relevant, so why care about if before that time?), you can find out the answer by just automating the job of looking at the _data_. It's easy. The question makes it obvious by its nature. The question is the thing that gives you the specifics that makes the search possible in the first place.

And _this_ is why the data matters. Renames and file boundaries do not. And until you accept that, you just limit yourself.

		Linus