Thread (5 messages) flat view 5 messages, 2 authors, 2016-06-15

Re: Adding Git to Better SCM Initiative : Comparison

From: Jakub Narebski <hidden>
Date: 2016-06-15 22:44:05

On Mon, 14 January 2008, Dmitry Potapov wrote:
On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help