Re: Errors GITtifying GCC and Binutils

From: Junio C Hamano <junkio@cox.net>
Date: Mar 23, 2006, 23:51 UTC
Message-ID: <7vacbg4t48.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060323210215.GH26071@mythryan2.michonline.com>

Ryan Anderson <ryan@michonline.com> writes:

> Git has taken a very pragmatic approach, in that the goal has been "What
> is the smallest number of concepts we can create that let us solve the
> problem, even if we occassionally have to make some tradeoffs?"
> (Thinking of rename detection there, mostly.)

I do not see it as a tradeoff not to record renames. It _is_ a feature.

On the other hand, rename detection is an eye candy, which is sometimes useful but only sometimes. If you look at the history of a real project, content movement across multiple files is a norm, and content movement between two files, one of which disappears and the other appears, is a rather narrow special case. If you think in terms of "renames", you can only talk about that special case, and rename detection also can only deal with that special case.

Two good examples were discussed some time ago on the list. One was about "where did {powerpc,pcc64}/Makefile come from?" and the answer was "content migrated over time across multiple commits, and you cannot really say this Makefile is renamed from somewhere". The other was the comment by Linus on how revision.c evolved in our project.

I am reasonably happy with how our rename detection turned out to be, but we should keep in mind that detecting file renames is scratching only a narrowly defined subset of the problem space.

Pickaxe was an attempt to help tracking other forms of content movement, and it is minimally useful as a building block, but if we really want to track content movement across file boundaries, like Linus originally envisioned in

	http://article.gmane.org/gmane.comp.version-control.git/217

we need to have a bit more Porcelain around it.