Re: Rename handling

[Daniel Barkalow <barkalow@iabervon.org>]

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*