On Fri, 15 Apr 2005, David Woodhouse wrote:
>
> And when I'm looking for the change that broke something, I can almost
> always tell which file it's in and go looking in _that_ file.
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.
> It's not about ditching the per-tree tracking and doing per-file
> tracking instead. I agree that would be wrong. It's about storing enough
> information to track what happened to given content as it moved around
> within the tree.
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
