Re: Adding Git to Better SCM Initiative : Comparison

From: Jakub Narebski <jnareb@gmail.com>
Date: Jan 13, 2008, 16:25 UTC
Message-ID: <200801131725.09301.jnareb@gmail.com>
In-Reply-To: <vpqd4s5ycvv.fsf@bauges.imag.fr>

On Sun, 13 January 2008, Matthieu Moy wrote:

> linux@horizon.com writes:

Can't you use a name or nick, by the way?

Show 13 quoted lines

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