From: Florian Weimer <fw@deneb.enyo.de>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, Shlomi Fish <shlomif@iglu.org.il>
Subject: Re: Adding Git to Better SCM Initiative : Comparison
Date: Mon, 10 Dec 2007 17:28:19 +0100 [thread overview]
Message-ID: <87r6huldjw.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <m34peqtuuj.fsf@roke.D-201> (Jakub Narebski's message of "Mon, 10 Dec 2007 07:47:49 -0800 (PST)")
* Jakub Narebski:
> 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.
>> > + <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.
>> > + <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.
> 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.
>> 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).
next prev parent reply other threads:[~2007-12-10 16:28 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-10 12:57 Adding Git to Better SCM Initiative : Comparison Jakub Narebski
2007-12-10 13:09 ` Eyvind Bernhardsen
2007-12-10 13:20 ` Jakub Narebski
2007-12-10 14:33 ` David Kastrup
2007-12-10 14:49 ` Florian Weimer
2007-12-10 15:23 ` Johannes Schindelin
2007-12-10 15:36 ` Florian Weimer
2007-12-10 15:47 ` Jakub Narebski
2007-12-10 16:28 ` Florian Weimer [this message]
2007-12-10 16:38 ` Linus Torvalds
2007-12-10 16:50 ` Chris Shoemaker
2007-12-10 17:21 ` Jakub Narebski
[not found] ` <200801071057.27710.shlomif@iglu.org.il>
2008-01-13 0:44 ` Jakub Narebski
2008-01-14 0:14 ` Dmitry Potapov
2008-01-14 0:31 ` Jakub Narebski
2008-01-14 6:58 ` Dmitry Potapov
2008-01-14 12:14 ` Jakub Narebski
-- strict thread matches above, loose matches on Subject: below --
2008-01-13 15:05 linux
2008-01-13 15:16 ` Matthieu Moy
2008-01-13 16:25 ` Jakub Narebski
2008-01-13 18:42 ` linux
2008-01-13 19:20 ` linux
2007-11-28 22:39 Jakub Narebski
2007-11-29 1:48 ` Robin Rosenberg
2007-11-29 7:17 ` Jan Hudec
2007-11-29 2:26 ` Jakub Narebski
2007-11-29 20:07 ` Alex Riesen
2007-11-30 0:18 ` Jakub Narebski
2007-11-30 1:26 ` Johan Herland
2007-11-30 1:53 ` Jakub Narebski
2007-11-30 7:16 ` Alex Riesen
2007-11-30 18:34 ` Jan Hudec
2007-12-03 19:57 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r6huldjw.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=shlomif@iglu.org.il \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).