On Mon, 19 Mar 2007, Steven Grimm wrote:
> John Goerzen wrote:
> > 2) For me, a rename is a logical change to the source tree that I want
> > to be recorded with absolute certainty, not guessed about later.
> > Sometimes I may make API changes and it is useful to see how module
> > names changed, with complete precision, later. I do not want to be
> > victim to an incorrect guess, which could be possible.
> >
>
> If you commit your renames separately from your content changes, it'll be
> unambiguous and you won't have to worry about it. That's what I usually do
> when this is a concern and it has yet to break for me.
>
> On the other hand, I agree with your general point; I really don't like being
> uncertain about whether renames are going to come out correctly or not ("it
> has always worked before" and "it is by design unable to fail" are two very
> different things.) In particular, I strongly disagree with the "names are just
> syntactic sugar, it's the content we're tracking" philosophy.
We are tracking the names as part of the content. They're right there in
the tree objects. It's not like, when you check out an older revision, you
could get the right content under the wrong name. The philosophy is
actually that we're tracking a series of states, and we're somewhat
agnostic on the description of the difference between two states. And it
often makes sense to postpone trying to describe this difference until you
know why you want to know, because it's certainly possible that there are
multiple reasonable interpretations, and some may give better results than
others.
If you're trying to merge a rename-and-refactor change (often something
like splitting a source or header file into two files) with a
modification, and it's arguable what happened in the refactor, the
interpretation which gives the state that's easiest to resolve correctly
may depend on what the modification is. So you really want to leave it up
to the merge code to choose the best guess at the result, without using a
fixed description of what the changes are.
As for whether names or contents "matter more", we have both answers. "git
log <names>" gives you the history of what has happened to change what
appears with those names. "git blame <name>", on the other hand, gives you
the history of the content which now appears at that name. You just need
to ask the question you want the answer to.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html