Re: Adding Git to Better SCM Initiative : Comparison

From: Florian Weimer <fw@deneb.enyo.de>
Date: Dec 10, 2007, 16:28 UTC
Message-ID: <87r6huldjw.fsf@mid.deneb.enyo.de>
In-Reply-To: <m34peqtuuj.fsf@roke.D-201>

* Jakub Narebski:

Show 15 quoted lines

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

It's undoubtly a difficult question. In my experience, developers tend to not mark renames properly, so rename detection in log/diff/annotate is still helpful even if renames are encoded explicitly. But this was a learning process; I used to think that explicit rename support was essential.

Show 10 quoted lines

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

Uhm, I'd commit something that references some SHA-1, and voilà, I can read the object with that SHA-1.

Show 14 quoted lines

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

Hmm.

Show 5 quoted lines

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

Makes sense, especially since there's "git bundle" nowadays.

Show 5 quoted lines

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

I think we disagree on the meaning of "close" here. 8-/

In my experience, it's hard to see the parallels between GIT and CVS because the semantics are so different. This is, to some extent, unavoidable. But I'm not sure if knowing your way around CVS actually helps learning GIT (the old sayings about BASIC come to my mind).