Adding Git to Better SCM Initiative : Comparison

> On 10. des. 2007, at 13.57, Jakub Narebski wrote:
> 
>> I have noticed that your SCM comparison at "Better SCM Initiative"
>> website
>>   http://better-scm.berlios.de/comparison/comparison.html
>> misses one of the Git, version control system which is used to manage
> 
> "misses one of the Git"?

> +                <s id="git">
> +                    Yes. Changesets are supported.<br />
> +                    Actually Git is snapshot based which means Git records
> +                    the full state in every commit.  This means that any two
> +                    commits can be compared directly very quickly, although the
> +                    repository is typically browsed as a series of changesets.
> +                </s>

> +                <s id="git">
> +                    Yes. (git blame, git gui blame).
> +                    It can also detect the origin of copied and moved source
> +                    lines, and can ignore whitespace changes.
> +                </s>

> @@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
>                      Yes, using "darcs whatsnew".
>                  </s>
>                  <s id="aegis">Yes. Using aediff</s>
> +                <s id="git">
> +                    Yes, of course. Using git diff.
> +                    Note that git uses staging area for commits (index).
> +                </s>

> @@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
>                  <s id="darcs">
>                      No.
>                  </s>
> +                <s id="git">
> +                    No.  The message applies to the commit as a whole.
> +                    But you can tag (with description) given contents
> +                    of a file (blob).
> +                </s>

> @@ -1006,6 +1075,13 @@ <title>Command Set</title>
>                      but since the model is different most commands are
>                      unique.
>                  </s>
> +                <s id="git">
> +                    Tries to follow CVS conventions, but deviates where there
> +                    is a different design (following BitKeeper for DVCS).

> @@ -1203,6 +1286,11 @@ <title>Portability</title>
>                      Very good. Supports many UNIXes, Mac OS X, and Windows,
>                      and is written in a portable language.
>                  </s>
> +                <s id="git">
> +                    Good to very good.  Portable across all POSIX systems.
> +                    There exists Win32 binary using MinGW (msysGit),
> +                    or you can use binary provided by Cygwin.
> +                </s>

> * Jakub Narebski:
> 
> > +                <s id="git">
> > +                    Yes (or no depending on interpretation). Git
> 
> This should be "No." (same for copies below).

>> > +                <s id="git">
>> > +                    Yes (or no depending on interpretation). Git
>> 
>> This should be "No." (same for copies below).
>
> Nice.  I have no idea what you are talking about, as you only quoted the 
> answer, but not the question. 

> > +                <s id="git">
> > +                    Partial (?). It is possible to lock down repository
> > +                    (access to branches and tags) using hooks.
> > +                </s>
> 
> I doubt this works reliably.  You still can access data once you've got
> its SHA1 hash, for instance.

> > +                <s id="git">
> > +                    Yes. Changesets are supported.<br />
> > +                    Actually Git is snapshot based which means Git records
> > +                    the full state in every commit.  This means that any two
> > +                    commits can be compared directly very quickly, although the
> > +                    repository is typically browsed as a series of changesets.
> > +                </s>
> 
> I don't think this explanation is necessary.  What does Subversion say?

> > +                <s id="git">
> > +                    Yes. (git blame, git gui blame).
> > +                    It can also detect the origin of copied and moved source
> > +                    lines, and can ignore whitespace changes.
> > +                </s>
> 
> A simple "Yes." should suffice.

> > @@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
> >                      Yes, using "darcs whatsnew".
> >                  </s>
> >                  <s id="aegis">Yes. Using aediff</s>
> > +                <s id="git">
> > +                    Yes, of course. Using git diff.
> > +                    Note that git uses staging area for commits (index).
> > +                </s>
> 
> Simply "Yes.".  "git diff" is wrong, it's actually "git diff HEAD".

> > @@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
> >                  <s id="darcs">
> >                      No.
> >                  </s>
> > +                <s id="git">
> > +                    No.  The message applies to the commit as a whole.
> > +                    But you can tag (with description) given contents
> > +                    of a file (blob).
> > +                </s>
> 
> Have we got any real tool support for this?  This should be "No.".

> > @@ -1006,6 +1075,13 @@ <title>Command Set</title>
> >                      but since the model is different most commands are
> >                      unique.
> >                  </s>
> > +                <s id="git">
> > +                    Tries to follow CVS conventions, but deviates where there
> > +                    is a different design (following BitKeeper for DVCS).
> 
> I don't think this is true.  Is there any command that closely matches
> what CVS does?

> > @@ -1203,6 +1286,11 @@ <title>Portability</title>
> >                      Very good. Supports many UNIXes, Mac OS X, and Windows,
> >                      and is written in a portable language.
> >                  </s>
> > +                <s id="git">
> > +                    Good to very good.  Portable across all POSIX systems.
> > +                    There exists Win32 binary using MinGW (msysGit),
> > +                    or you can use binary provided by Cygwin.
> > +                </s>
> 
> Isn't Windows support still a bit lacking in terms of performance?

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> * Jakub Narebski:
>> > @@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
> [...]
>> > +                <s id="git">
>> > +                    Yes (or no depending on interpretation). Git
>> 
>> This should be "No." (same for copies below).
>
> I would agree to "N/A" or "Partial", but with 'git log --follow'
> implemented at least for single file I wouldn't say that that git
> doesn't support file and directories renames (copies).  It does, in
> it's own fashion, using rename (copy) detection instead of rename
> (copy) tracking.

>> > +                <s id="git">
>> > +                    Partial (?). It is possible to lock down repository
>> > +                    (access to branches and tags) using hooks.
>> > +                </s>
>> 
>> I doubt this works reliably.  You still can access data once you've got
>> its SHA1 hash, for instance.
>
> So what? The data is not visible, so it is as if it didn't
> exist.

>> > +                <s id="git">
>> > +                    Yes. Changesets are supported.<br />
>> > +                    Actually Git is snapshot based which means Git records
>> > +                    the full state in every commit.  This means that any two
>> > +                    commits can be compared directly very quickly, although the
>> > +                    repository is typically browsed as a series of changesets.
>> > +                </s>
>> 
>> I don't think this explanation is necessary.  What does Subversion say?
>
> Subversion has the following currently:
>
>   Partial support. There are implicit changeset that are generated on
>   each commit.

> Well, we could follow Mercurial, Monotone and Darcs and simply write
>
> +                <s id="git">
> +                    Yes. Changesets are supported.
> +                </s>

>> I don't think this is true.  Is there any command that closely matches
>> what CVS does?
>
> Yes: init, add, annotate (alias to blame), checkout, commit, diff,
> status, log, version. At least in principle, if not in output format.

> * Jakub Narebski:
> 
> > +                <s id="git">
> > +                    Yes (or no depending on interpretation). Git
> 
> This should be "No." (same for copies below).

> * Jakub Narebski:
> 
> > +                <s id="git">
> > +                    Yes (or no depending on interpretation). Git
> 
> This should be "No." (same for copies below).

> On Mon, Dec 10, 2007 at 03:49:39PM +0100, Florian Weimer wrote:
> > * Jakub Narebski:
> > 
> > > +                <s id="git">
> > > +                    Yes (or no depending on interpretation). Git
> > 
> > This should be "No." (same for copies below).
> 
> ISTM that people are stuck using less than helpful criteria for
> judging whether renames are supported.  Namely, in effect, they ask:
> "Does the user get to do extra work in order to get rename-detection?"
> 
> Let me humbly suggest an alternate, two-fold, very practical criteria
> that I actually care about as a user:
> 
> 1) If I edit file A, while another developer renames file A to B, and
> I merge my work with his, do I have to clean things up myself, or does
> everything Just Work?

> 
> I'm CCing all the correspondents, because I'm banned from the vger.kernel.org 
> mail. This has been an obstacle for me in several legitimate occassions and 
> this one is the latest. I'm still CCing it, so the people in the mailing list 
> will receive the replies.
> 
> On Monday 10 December 2007, Jakub Narebski wrote:
> > I have noticed that your SCM comparison at "Better SCM Initiative"
> > website
> >   http://better-scm.berlios.de/comparison/comparison.html
> > misses one of the Git, version control system which is used to manage
> > Linux kernel, and one of the main open source (distributed) version
> > control systems (among Mercurial, Bazaar-NG, Monotone and Darcs).
> >
> 
> Indeed git is absent. That's because no one until you has volunteered to send 
> a patch that adds it to the comparison. Another requirement is for someone to 
> volunteer to become a "champion" for the version control system and maintain 
> it into the future. So who is going to be the champion?

> > Below there is (slightly doctored) patch to the sources for the site.
> >
> 
> Despite the fact that I the comparison was recently patched to add Bazaar and 
> fix some grammatical problems, the patch still applies cleanly. However, I 
> saw that some people commented on it here. Can you send me a new patch 
> integrating all this commentary?

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

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

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

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

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

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

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

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

> > 
> > 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? -:)