On Sun, 24 Jun 2007, Dan Chokola wrote:
What I have noticed is a lot of nitpicking, of which I'm guilty, too. The
issue Linus brought up about Darcs and versioning is not one I typically see
surface in real life. Users usually complain about some _release_ version
or, "I updated last week."
Actually, in the kernel, we are getting quite a lot out of "git bisect",
and people throw git SHA1's around to describe where they are, or a
particular commit.
Which never happened with BK.
So I think that the _ability_ to name revisions easily across different
uses is quite important, because it then drives behaviour.
Without it, you'll never notice you need it. With it, you start wondering
how others handle it.
For example, we have people like Andrew, who don't really "use" git, and
he starts pointing to commits with their git ID, because he sees them
flying past, and he knows they are stable and useful for things like
gitweb.
Linus
On 6/24/07, Linus Torvalds [off-list ref] wrote:
On Sun, 24 Jun 2007, Dan Chokola wrote:
quoted
What I have noticed is a lot of nitpicking, of which I'm guilty, too. The
issue Linus brought up about Darcs and versioning is not one I typically see
surface in real life. Users usually complain about some _release_ version
or, "I updated last week."
Actually, in the kernel, we are getting quite a lot out of "git bisect",
and people throw git SHA1's around to describe where they are, or a
particular commit.
Which never happened with BK.
So I think that the _ability_ to name revisions easily across different
uses is quite important, because it then drives behaviour.
I wholeheartedly agree it's important as far as the big picture of SCM
is concerned. Though I will say that the kernel development is an
extreme case, where there's a huge number of developers and incredibly
fast development where matching features are needed from the SCM. And
I love how Git is born out of this extreme case, as it leads to a lot
of great features that often scale down, too. But some of them matter
less to, say, a small, well-integrated team of 5 or 10 people. And an
idealistic model like the one offered by Darcs might even work better
there since corner cases don't show up often.
I'm spoiled by Git and the fact that it has these great abilities and
features that set it apart, and I'd love everyone to use it. But I'd
like people to know that many attributes of Git and other DSCMs don't
differ all that much. (Please don't call me ugly and stupid. ;) And
actually, this is something of a selling point, because it makes it
Git seem cozy and familiar.
So, relating back to the original post, and extending on Linus'
'academic' analogy, Darcs is like a thesis project from university
that proves how DSCM can be done scientifically. Git is grown-up Darcs
that proves how DSCM can be done practically. The bottom line is the
foundations of DSCM, cheap branching, easy merging, and the like, can
be done very similarly in either Darcs or Git, so moving from one to
the other leaves you with a largely familiar set of commands.
Without it, you'll never notice you need it. With it, you start wondering
how others handle it.
Git really does have a way of spoiling its users (I don't know how
CVS/SVN users live), no argument here.
-Daniel "Puzzles" Chokola
On 6/25/07, Dan Chokola [off-list ref] wrote:
So, relating back to the original post, and extending on Linus'
'academic' analogy, Darcs is like a thesis project from university
that proves how DSCM can be done scientifically. Git is grown-up Darcs
that proves how DSCM can be done practically.
I don't think it's like that. More like
- BK showed it's done
- Darcs picked some good bits from BK (while no other foss dscm did
until git/hg/bzr came along) but got distracted with interesting but
not-that-useful stuff - see patch algebra.
cheers,
m