Re: Adding Git to Better SCM Initiative : Comparison

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 14 January 2008, Dmitry Potapov wrote:
> On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:
> > 
> > What does "Renames Support" mean? 

By the way, the question was to the author of Better SCM Initiative
Comparison, Shlomi Fish.

> Accordingly to the clarification provided there, it means retaining the
> history of the file when its name changed. So I would write like this:
> 
> Yes. Git can automatically detects renames and show history together,
> however being content oriented rather than file oriented, the notion of
> "retaining the history of the file" can not exactly applied to it.

"History of a file" can be defined as "<scm> log 'file'", and this is
well defined also for git. And 'rename support' for file means just
that this history of a file (of a current file contents) follows file
renames.

IIRC this des not work for directories... but on the other hand git,
tracking contents only as a goal, does not track directories.

> > Because the answer,
> > especially in the case of git which is a bit different in that it does
> > rename detection and not rename tracking (using inodes / file-ids),
> > depends on that...
> 
> Git is different in that it tracks the content as the whole rather than
> tracking a set of files. When you look at some source code, what you
> really want to know who and why wrote *this*, and usually it does not
> matter to you whether it was written in this file or another one. CVS
> is really bad at that, because if you renamed a file, it would be very
> difficult to go back to history and find that. Many file-ids based SCMs
> have solved this problem, however, they do not do any better than CVS
> in another very common case -- when your code is moved around as result
> of refactoring, but Git addresses both problems, not just one!

AFAIK Mercurial (hg) is not file-id based, but does explicitely track
renames. There was even an idea presented on git mailing list to mark
renames in commit object in some "note" header.

> So, it is not as much about explicit renaming vs automatic, but about
> different design goals. After finishing reading this questionnaire,
> it seems to me that a more proper title for it would be "Better CVS
> Initiative", so it is not surprisingly that Git does not fit into it
> well. It is like trying to put characteristics of your LCD into a
> questionnaire for CRT monitors -- some does not make sense, other
> misleading, and most important ones are not mentioned anyway...

Please remember that AFAIK this table is _older_ than Git itself.
But it is a fact that some characteristics are much patterned after
CVS features and misfeatures.

It would be much better if for each feature there was some test
described which would allow to check if the feature is supported.

By the way, even before "git log --follow" you could have "this file
was renamed to that file" in the commit/revision patchset. This is
IMHO enough of rename support. Much more important is correct support
for renames in merges, which is in TODO for Better-SCM comparison...

-- 
Jakub Narebski
Poland