Re: VCS comparison table

Andy Whitcroft wrote:

Aaron Bentley wrote:

quoted

quoted

quoted

Git supports renames in its own way; it doesn't use file ids, nor
remember renames (the new "note" header for use e.g. by porcelains 
didn't pass if I remember correctly). But it does *detect* moving
_contents_, and even *copying* _contents_ when requested. And of
course it detect renames in merges.

You'll note we referred to that bevhavior on the page.  We don't think
what Git does is the same as supporting renames.  AIUI, some Git users
feel the same way.

In my experience there are two key features to rename support.  The
first that files move about efficiently ie. we don't have to carry a
different copy of the same file for each name it has had, this git
handles nicely.  The second is the seemless following of history 'back',
this git does not do trivially (when limited to specific files).  git
log on a renamed file pretty much stops at the rename point and you have
deal with it yourself.

Both git log and git diff follows renames (with -M) and even copies 
(with -C), but path _limiter_ doesn't follow renames. There is proposal
to add --follow option to git rev-list to follow specified paths. There was
a patch adding this option here on git mailing list (check archives), not
added because it was fairly intrusive and not complete solution IIRC.

I'd say that the second part is _partially_ supported, as we can follow
history of renamed file with pathlimit, detect that file was renamed, and
follow using previous name as pathlimit. For example if you know all the
names the file had through history, you can get whole history providing all
those names as pathlimit (well, unless there is some conflict like creating
new file with the same name as file before rename; something that all
file-id based solutions have problem with).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git