Ryan Anderson <ryan@xxxxxxxxxxxxxx> 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.
-
: 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