Re: Adding Git to Better SCM Initiative : Comparison

[Jakub Narebski <jnareb@gmail.com>]

On Sun, 13 January 2008, Matthieu Moy wrote:
> linux@horizon.com writes:

Can't you use a name or nick, by the way?
 
> > "Rename support" is a kludge to make a fundamentally broken model
> > less painful.
> 
> It's not.
> 
> Git _has_ rename support. Look into the code, you'll find some code
> whose purpose is to manage renames. And _no_, rename support is not
> just a direct consequence of commits being atomic.
> 
> Atomic commit help, but if you do nothing else, moving a file and then
> trying to merge will fail for example. So, in addition to atomic
> commits, you have at least 3 options : explicit file ID (bzr),
> recording renames (hg), or detecting renames after-the-fact (git).

Rename detection / dealing with renames in SCMs is needed for:
0. Recovering previous state
1. Merging correct files
2. Forensic (log, blame) across renames / code movement

While the fact that Git is snapshot based and has whole-tree atomic
commits (Subversion does too) make it automatically obey 0., some
kind of rename support is needed for merges (Better SCM has it in TODO),
and for examining history, for example if the file was renamed in
one of the branches.

For example "git log --follow=gitweb/gitweb.perl" follows history of
specified file (IIRC this does not work for directory; but then Git
does not per se tracks directories), even if it was called gitweb.cgi
at the very beginning. "git blame -M" assign commit to a line denoting
when line was created, and not when it was moved (perhaps across file
boundaries) in the current place.

-- 
Jakub Narebski
Poland