Re: Rename handling

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Mar 19, 2007, 19:15 UTC
Message-ID: <Pine.LNX.4.64.0703191425560.6485@iabervon.org>
In-Reply-To: <45FED31B.8070307@midwinter.com>

On Mon, 19 Mar 2007, Steven Grimm wrote:

Show 17 quoted lines

> 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*