Re: Adding Git to Better SCM Initiative : Comparison

From: Jakub Narebski <jnareb@gmail.com>
Date: Jan 14, 2008, 12:14 UTC
Message-ID: <200801141314.21686.jnareb@gmail.com>
In-Reply-To: <20080114065810.GY2963@dpotapov.dyndns.org>

Dnia poniedziałek 14. stycznia 2008 07:58, Dmitry Potapov napisał:

Show 18 quoted lines

> On Mon, Jan 14, 2008 at 01:31:19AM +0100, Jakub Narebski wrote:
> > On Mon, 14 January 2008, Dmitry Potapov wrote:
> > 
> > > 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. 
> 
> You missed the key word here -- *retaining*. In fact, if you define the
> history of a file just as something what "<scm> log" produce then what
> is the problem with CVS here? Why do most people say that CVS does not
> retain file history over rename? Certainly, you can type "cvs old-name"
> and see history of one file, and if you type "cvs new-name" then history
> of another... But somehow most people think about these two pieces as
> being the history of *one* file... So, your definition is incorrect or,
> at least, very different from what most people mean by that.

I assume that 0th part of rename support is true, i.e. that we can recover previous full-tree state of repository.

> BTW, when you type "git log 'file'", it shows you not history of a file,
> but history of changes that affect the specified paths...

The fact that in "git log <path>" the <path> part is path _limiter_ (and can be directory, or set of directories) rather than being limited to simply single filename is what makes git different, both in good ("git log subsystem/path") and in bad (different from what other SCM used to) way.

When you type "git log --follow='file'", it shows you history of a _contents_ which currently is in 'file'; even if there were rename in the history of 'file' somewhere in the past.

When you type "git log 'directory'", it shows you (simplified) history of changes affesting specified directory (usually some subsystem).

IMHO "rename support" should be defined as
1.) showing renames when examining given revision (status, log, show;
    whatever it is called).
2.) it should be able to follow history of a file when it looks like
    this: add, change, rename, change.

> > And 'rename support' for file means just
> > that this history of a file (of a current file contents) follows file
> > renames.

[...]

Show 6 quoted lines

> > 
> > IIRC this des not work for directories... 
> 
> Git works for directories, it is just that the --follow option cannot
> applied to it, because this option means to follow the file contents,
> which does not make much sense for directories.

But it would be nice to have somehow "git log --follow=directory" work, even if directory in which susystem resides was renamed. It is harder work also because (I think) directories are more often split and joined than file[s contents].

Show 19 quoted lines

> > > 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.
> 
> I suspect the main reason why Mercurial support that is that a lot of
> programmers whose mind was mangled by many years of CVS experience asked
> for that feature. In practice, what you really want to track is contents.
> And it is not difficult to add some "note" to the commit and teach Git to
> follow it, but I don't see any practical value in that...

Mercurial can be IMHO from architecture point of view be viewed a bit as "CVS done right", much more than Subversion, with its path-hashed changeset storage, manifest file, and changelog / changerev file.

And I guess that Mercurial supports this because of the most important
part of "renames support" (which is present only as TODO for Better-SCM
comparison), namely merging correct files in presence of renames.

Show 5 quoted lines

> > 
> > It would be much better if for each feature there was some test
> > described which would allow to check if the feature is supported.
> 
> Wanna test your LCD monitor with some old CRT tests? -:)

If those tests were done correctly, not from technical side ("renames support" and other similar thingies for SCMs, refresh rate for LCD/CRT), but from user side (does command which shows history of a file follows renames, eyestrain / image sharpness for monitors).... :-)

-- 
Jakub Narebski
Poland