Walter asked me to post this to this list.
The Emacs D Mode project is at: https://launchpad.net/emacs-d-mode
and the group is at: https://launchpad.net/~emacs-d-mode-maintainers
It's only me just now, but hopefully there are other Emacs users and
ELisp capable people who will volunteer to join in so there is a
community that can ensure progress.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

I'm not a huge fan of Bazaar :-p ,
but thanks for putting it up somewhere more amenable to collaborative
revisioning than the wiki where it was!
I'll take Bazaar over a bizarre wiki interface any day.
--bb
On Mon, Oct 25, 2010 at 9:55 AM, Russel Winder <russel russel.org.uk> wrote:

Hummm... May I ask why?
Personally I think Bazaar, Mercurial and Git beat Subversion, CVS,
ClearCase, TFS, etc. always. Moreover Bazaar and Mercurial beat Git.
Overall I see two different best cases for Bazaar and Mercurial --
basically when it is important for file hierarchy to be a branch vs
having everything all in one repository.=20

but thanks for putting it up somewhere more amenable to collaborative
revisioning than the wiki where it was!
I'll take Bazaar over a bizarre wiki interface any day.

Could someone please explain to me why is a VCS other than the three big
ones (SVN, Git and HG) is worth using for an open-source project such as
this?
I have never used Bazaar, DARCS and Monotone, and only briefly used HG,
and I acknowledge that they may be better than Git in some aspects.
However, IMHO, one of the main decisions for a VCS for a public project is
its accessibility. SVN is the most popular one, but it's pretty
established that SVN isn't anywhere as productive as DVCSes, and obviously
it can't be used in a distributed manner.
If I'd consider contributing to an open-source project using a VCS I'm
unfamiliar with, it's quite likely that I'd get turned off by the hurdle
of downloading, installing and learning to use the respective VCS.
Russel wrote in another, unrelated thread:

Of course using BitBucket or Launchpad may well be more likely to get
support as Mercurial and Bazaar are so much more usable that Git.

I'm sorry, but to me that sounds like a biased personal opinion stated as
if it was an objective fact :( I seriously doubt that any project would
get more "support" if it used an obscure (albeit possibly better in some
ways) DVCS, unless the intended audience for the project's contributors is
already familiar with that DVCS. Maybe Bazaar etc. is more popular with
EMACS users/hackers?
Also, I think that it's pretty hard to beat the workflow that GitHub
facilitates for open-source projects (with one-click forking and pull
requests).
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Vladimir> Could someone please explain to me why is a VCS other than
Vladimir> the three big ones (SVN, Git and HG) is worth using for an
Vladimir> open-source project such as this?
Maybe it's personal preference...I still find darcs' cherry-picking
and it's UI incomparable to the rest.
Otoh, I consider that e.g. Monotone is much better designed than Git
so will use it for my own project(s).
Vladimir> If I'd consider contributing to an open-source project using
Vladimir> a VCS I'm unfamiliar with, it's quite likely that I'd get
Vladimir> turned off by the hurdle of downloading, installing and
Vladimir> learning to use the respective VCS.
I think that any capable developer can quickly grasp any of the
'standard' (bzr,hg,git,mtn) DVCS-es (darcs is a little bit different
considering it's patch-oriented) and can do:
dvcs init; dvcs pull; dvcs commit; dvcs push;=20
easily.
Vladimir> I'm sorry, but to me that sounds like a biased personal
Vladimir> opinion stated as if it was an objective fact :( I seriously
Vladimir> doubt that any project would get more "support" if it used an
Vladimir> obscure (albeit possibly better in some ways) DVCS, unless
Vladimir> the intended audience for the project's contributors is
Vladimir> Maybe Bazaar etc. is more popular with EMACS users/hackers?
Emacs is stored in Bazaar repo.
Vladimir> Also, I think that it's pretty hard to beat the workflow that
Vladimir> GitHub facilitates for open-source projects (with one-click
Vladimir> forking and pull requests).
Can you explain more about this 'hard to beat workflow' which is not
supported by other DVCS-es mentioned above?
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

I think that any capable developer can quickly grasp any of the
'standard' (bzr,hg,git,mtn) DVCS-es (darcs is a little bit different
considering it's patch-oriented) and can do:
dvcs init; dvcs pull; dvcs commit; dvcs push;
easily.

IIRC even those commands differ across these DVCSes. Anyway, when you want
to do something non-trivial (branching/merging/history editing) you're
forced to consult the documentation.

Can you explain more about this 'hard to beat workflow' which is not
supported by other DVCS-es mentioned above?

It's not really about Git, it's about GitHub:
1. Repo creation is instant, doesn't need to go through a human approval
process, etc. (big turn-off from DSource, SourceForge as I create and work
on many small projects)
2. One-click forking - self-explanatory, you get a cheap clone of a
project in your own namespace, to which you can push to to instantly
publish your changes.
3. Pull requests - pretty self-explanatory, but integrated with the issue
system.
4. You've probably seen one of GitHub's "network chart"?
( e.g.: http://github.com/jquery/jquery/network )
You can instantly see activity of all of the project's forks on GitHub.
This allows easily finding nice forks to merge / cherry-pick. If you're
lazy, you don't even need to send your patches upstream - as long as you
don't change the license, the project maintainers can cherry-pick from
your fork as long as you push them to your fork. Personally, I think this
feature is revolutionary, and quite "hard to beat" compared to the
oldschool approach of mailing lists etc. ;)
GitHub has other nice things, such as line-level commit comments, as well
as the usual things you'll find in many other open-source project hosters
(issues, wiki, HTML project homepage).
And finally, IMHO a pretty convincing argument is that GitHub is one of
the most popular open-source hosting websites. Not having to register and
familiarize yourself with a project hosting website lowers the
contribution barrier even lower.
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Vladimir> IIRC even those commands differ across these DVCSes.=20
In some details, yes.
Vladimir> Anyway, when you want to do something non-trivial
Vladimir> (branching/merging/history editing) you're forced to consult
Vladimir> the documentation.
Sure. But all those are quite similar in nature...Besides that, there
are plugins which enable, to some extent, interoperability. There are
e.g. bzr-{hg,svn,git} plugins so one can stay using bzr with other
DVCS-es as well.
Vladimir> It's not really about Git, it's about GitHub:
That's another thing and does not have much with Git itself.
Vladimir> 1. Repo creation is instant, doesn't need to go through a
Vladimir> human approval process, etc. (big turn-off from DSource,
Vladimir> SourceForge as I create and work on many small projects)
Vladimir> 2. One-click forking - self-explanatory, you get a cheap
Vladimir> clone of a project in your own namespace, to which you can
Vladimir> push to to instantly publish your changes.
Vladimir> 3. Pull requests - pretty self-explanatory, but integrated
Vladimir> with the issue system.
Vladimir> 4. You've probably seen one of GitHub's "network chart"?
Vladimir> ( e.g.: http://github.com/jquery/jquery/network )
I believe you didn't try much of the competition like Launchpad,
Bitbucket, Gitorious etc.
What you are describing is neither very special nor specific to
Github.
Vladimir> And finally, IMHO a pretty convincing argument is that GitHub
Vladimir> is one of the most popular open-source hosting websites. Not
Vladimir> having to register and familiarize yourself with a project
Vladimir> hosting website lowers the contribution barrier even lower.
Try some of the above hosting solutions.
Btw, I'll probably use www.indefero.net as soon as the monotone
support gets in (probably next week).
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

I believe you didn't try much of the competition like Launchpad,
Bitbucket, Gitorious etc.

You're right, I haven't used them for my own projects, but I did look at
them briefly.

What you are describing is neither very special nor specific to
Github.

I must be blind - I just looked at all of the hosting solutions you
mentioned, and this is what I saw:
Launchpad: Looking at https://launchpad.net/bzr I see absolutely no
mention of branching/forking.
Bitbucket: http://bitbucket.org/tortoisehg/stable/descendants shows an
unformatted, almost-unreadable list of forks.
Gitorious: http://qt.gitorious.org/qt/repositories takes forever to load,
and when it does it shows a list of widgets for each fork, with no useful
information except the name of the repository (usually
username~"-"~projectname).
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Vladimir> Launchpad: Looking at https://launchpad.net/bzr I see
Vladimir> absolutely no mention of branching/forking.
Try https://code.launchpad.net/bzr
Vladimir> Bitbucket: http://bitbucket.org/tortoisehg/stable/descendants
Vladimir> shows an unformatted, almost-unreadable list of forks.
Well, it's question of bitbucket's interface, nothing about git.
Vladimir> Gitorious: http://qt.gitorious.org/qt/repositories takes
Vladimir> forever to load, and when it does it shows a list of widgets
Vladimir> for each fork, with no useful information except the name of
Vladimir> the repository (usually username~"-"~projectname).
Ditto.
Otoh, when I have to choose DVCS, then I primarily look at its VCS
features and not so much about features of the public hosting which is
of secondary concern.
However, considering that there are no darcs solutions for public
hosting, I've decided to use Monotone (with indefero.net) instead.
Still, github with it's non-beatable workflow is not enough to
persuade me to use Git 'cause I'll work more with the DVCS than with
it's hosting UI.
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

Otoh, when I have to choose DVCS, then I primarily look at its VCS
features and not so much about features of the public hosting which is
of secondary concern.
However, considering that there are no darcs solutions for public
hosting, I've decided to use Monotone (with indefero.net) instead.
Still, github with it's non-beatable workflow is not enough to
persuade me to use Git 'cause I'll work more with the DVCS than with
it's hosting UI.

While I agree that it doesn't really matter what anyone uses for personal
projects, I wouldn't choose anything non-mainstream for an open-source
project where community involvement is important. For example, I think
that moving DMD/Phobos/DRuntime from SVN to Bazaar/Monotone/DARCS would be
a very bad idea (and I think that GitHub's featureset would fit D's
community perfectly).
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Vladimir> While I agree that it doesn't really matter what anyone uses
Vladimir> for personal projects, I wouldn't choose anything
Vladimir> non-mainstream for an open-source project where community
Vladimir> involvement is important.=20
It really depends...Sqlite is one of the very successful open-source
projects and you can check for yourself which VCS it uses. ;)
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

While I agree that it doesn't really matter what anyone uses for
personal projects, I wouldn't choose anything non-mainstream for an
open-source project where community involvement is important. For
example, I think that moving DMD/Phobos/DRuntime from SVN to
Bazaar/Monotone/DARCS would be a very bad idea (and I think that
GitHub's featureset would fit D's community perfectly).
=20

Readable version of the link:
http://www.netmarketshare.com/os-market-share.aspx?qprid=11
Wow, I had no idea I was in such a large majority by sticking to XP over
Win7 (I *really* don't like Win7 compared to XP). Then again, maybe that gap
is just from a bunch of major corporations not getting around to switching
just yet?

Woah! I knew Hg's user base was smaller than Git's, but I never expected
the difference to be so huge. That removes any doubt I had whether to
consider Hg for any of my own projects.
Another page with interesting statistics:
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities#Popularity
GitHub trumps pretty much everything. Its project count probably includes
forks, though - but I wouldn't be surprised if it wasn't, considering how
easy it is to just put anything on GitHub.
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

=20
I use Git on Windows. Never had any problems. :D
=20
Yes, I know Git was bad on Windows. Was :)
=20

Last year, someone convinced me to give git another chance on
Windows with the same argument ("was bad, made a lot of progress, is
now very good"). My conclusion was: "was *very* bad, made a lot of
progress, still a long way to go before I would consider it usable
on windows".
Anyway, I don't see any point in using Git since Mercurial can sync
just fine with a Git repository :)
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Last year, someone convinced me to give git another chance on
Windows with the same argument ("was bad, made a lot of progress, is
now very good"). My conclusion was: "was *very* bad, made a lot of
progress, still a long way to go before I would consider it usable
on windows".

I started using Git in October 2009, so I probably missed the bad times.

Anyway, I don't see any point in using Git since Mercurial can sync
just fine with a Git repository :)

Well, the topic at hand was which VCS to use for an open-source project.
Using your argument, there is no reason to use Mercurial over Git, because
Mercurial users can sync just fine with Git repositories :)
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

=20
Well, the topic at hand was which VCS to use for an open-source project=

=2E

Using your argument, there is no reason to use Mercurial over Git,
because Mercurial users can sync just fine with Git repositories :)
=20

Well, Mercurial offers much less opportunities to shoot oneself in
the foot and is much easier to use. This is especially true if you
come from another VCS like SVN: you can use the same commands for
the same results on the local repository and you only need to learn
a couple of commands for syncing. Git uses different commands for
everything (this is actually a stated design goal: try to make
things as different from CVS as possible!)
The only true advantage that Git has over Mercurial is the staging
area, and even that is a two edged sword: IMO it should not be
enabled by default since it helps people to lose data. And the same
functionality can be emulated (and superseded) in Mercurial with
record and mq anyway.
So, why use Mercurial?
- It is safer to work with: make a change, commit, your change is in
the repository. With git, you need to "add" your change before
committing (or remember to use the correct option when committing,
"-a" IIRC);
- It is easier to use when you come from another VCS (and even when
you do not: try to figure out from the Git doc how to revert a
change you've made but not yet committed);
- It is safer on Windows: in six years, I have never had a data loss
or corruption, whereas I've had both with Git in a two days test
without doing anything special;
- It is faster on Windows (not by much for most operations, but
sometimes spectacularly so);
- Repositories are smaller on Windows (ok, that's not so important
given the price of HDDs today);
- If you are already a Python user, it is only a very small package
to add whereas Git installs a lot of cruft that you won't be able to
use anyway even if you wanted to.
Why use Git?
- You know someone who uses it and will be able to guide you through
all the pitfalls;
- You really, really, really *always* need the staging area so you
want to have it by default instead of using mq. If that is the case,
you will probably wind up using quilt anyway (quilt is the Git
equivalent for mq).
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

The only true advantage that Git has over Mercurial is the staging
area, and even that is a two edged sword: IMO it should not be
enabled by default since it helps people to lose data. And the same
functionality can be emulated (and superseded) in Mercurial with
record and mq anyway.

Could you please explain to me how can the staging area cause you to lose
data? The only way I see that can happen is if you forget that you staged
some changes, then do "git diff" and think that your working directory
(and index) are clean.

- It is safer on Windows: in six years, I have never had a data loss
or corruption, whereas I've had both with Git in a two days test
without doing anything special;

Sorry, I don't consider this to be true at the moment based on my
experience.

- Repositories are smaller on Windows (ok, that's not so important
given the price of HDDs today);

How does that make sense? Doesn't Git use the same disk storage format
everywhere? :o

- You know someone who uses it and will be able to guide you through
all the pitfalls;

- You really, really, really *always* need the staging area so you
want to have it by default instead of using mq. If that is the case,
you will probably wind up using quilt anyway (quilt is the Git
equivalent for mq).

I think the staging area is an amazing feature, and I use it all the time,
but perhaps not in the way you imagine:
1) Hack up a bunch of changes
2) Fire up git gui
3) Quickly stage the chucks or lines you want to go into the first commit
(one case where using a mouse-driven GUI is way more productive...)
4) Type commit description, Ctrl+Enter to instantly commit
5) Repeat, until working directory is clean
This allows me to work freely on my code and edit different parts of it,
without having to worry that I should first commit / shelve unrelated
changes first.
Anyway, you make a convincing argument. I know that Hg's GUI tools are
more mature than Git's Tcl/Tk hacks (the official versions saw no
improvement since I started using Git), so it's worth looking at as a DVCS
client. Bazaar's GUI looks pretty mature as well.
(I dream of a day when I can cherry-pick by dragging and dropping commits,
and rebasing by selecting a range of commits and dragging-and-dropping it
on another branch. I don't think any Git GUIs have this.)
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Hey!
I know git gui (and gitk) isn't the all-singing, all-dancing,
command-line-shell-replacement (nor do I think that's even possible), but
what it can do, it does well.
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

area, and even that is a two edged sword: IMO it should not be
enabled by default since it helps people to lose data. And the same
functionality can be emulated (and superseded) in Mercurial with
record and mq anyway.

=20
Could you please explain to me how can the staging area cause you to
lose data? The only way I see that can happen is if you forget that you=

staged some changes, then do "git diff" and think that your working
directory (and index) are clean.
=20

git commit
git push # Is that the right command to send my changes
# to the main repo?
# OK, I'm done working on that
cd ..
rm -r myrepo
# Ooops

- It is safer on Windows: in six years, I have never had a data loss
or corruption, whereas I've had both with Git in a two days test
without doing anything special;

=20
Sorry, I don't consider this to be true at the moment based on my
experience.
=20

- Repositories are smaller on Windows (ok, that's not so important
given the price of HDDs today);

=20
How does that make sense? Doesn't Git use the same disk storage format
everywhere? :o
=20

- You really, really, really *always* need the staging area so you
want to have it by default instead of using mq. If that is the case,
you will probably wind up using quilt anyway (quilt is the Git
equivalent for mq).

=20
I think the staging area is an amazing feature, and I use it all the
time, but perhaps not in the way you imagine:
=20
1) Hack up a bunch of changes
2) Fire up git gui
3) Quickly stage the chucks or lines you want to go into the first
commit (one case where using a mouse-driven GUI is way more productive.=

=2E.)

4) Type commit description, Ctrl+Enter to instantly commit
5) Repeat, until working directory is clean
=20
This allows me to work freely on my code and edit different parts of it=

,

without having to worry that I should first commit / shelve unrelated
changes first.
=20

Well, Mercurial offers much less opportunities to shoot oneself in
the foot and is much easier to use. This is especially true if you
come from another VCS like SVN: you can use the same commands for
the same results on the local repository and you only need to learn
a couple of commands for syncing. Git uses different commands for
everything (this is actually a stated design goal: try to make
things as different from CVS as possible!)
The only true advantage that Git has over Mercurial is the staging
area, and even that is a two edged sword: IMO it should not be
enabled by default since it helps people to lose data. And the same
functionality can be emulated (and superseded) in Mercurial with
record and mq anyway.

But isn't the staging area similar, if not identical to SVN? I mean, in
svn you also have to do a command "svn add" to add new files to the
"sandbox". They won't get commit otherwise, right?
(note: im somewhat familiar with SVN and Git, but not with Mercurial)
--
Bruno Medeiros - Software Engineer

Well, Mercurial offers much less opportunities to shoot oneself in
the foot and is much easier to use. This is especially true if you
come from another VCS like SVN: you can use the same commands for
the same results on the local repository and you only need to learn
a couple of commands for syncing. Git uses different commands for
everything (this is actually a stated design goal: try to make
things as different from CVS as possible!)
The only true advantage that Git has over Mercurial is the staging
area, and even that is a two edged sword: IMO it should not be
enabled by default since it helps people to lose data. And the same
functionality can be emulated (and superseded) in Mercurial with
record and mq anyway.

But isn't the staging area similar, if not identical to SVN? I mean, in
svn you also have to do a command "svn add" to add new files to the
"sandbox". They won't get commit otherwise, right?
(note: im somewhat familiar with SVN and Git, but not with Mercurial)

No, that only marks the file to be added in the next commit.
Compared to SVN, when you type "git add file", you copy the file entirely
into the index.
You can then continue editing it without changing that copy.
Git also allows you to only "stage" parts of a file, as I described in
another post.
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

the foot and is much easier to use. This is especially true if you
come from another VCS like SVN: you can use the same commands for
the same results on the local repository and you only need to learn
a couple of commands for syncing. Git uses different commands for
everything (this is actually a stated design goal: try to make
things as different from CVS as possible!)
The only true advantage that Git has over Mercurial is the staging=

area, and even that is a two edged sword: IMO it should not be
enabled by default since it helps people to lose data. And the same
functionality can be emulated (and superseded) in Mercurial with
record and mq anyway.

=20
But isn't the staging area similar, if not identical to SVN? I mean, in=

svn you also have to do a command "svn add" to add new files to the
"sandbox". They won't get commit otherwise, right?
=20
(note: im somewhat familiar with SVN and Git, but not with Mercurial)
=20

No, because in Git if you make changes to an existing file, you
need to "add" that file again. In both SVN or Mercurial, you need to
"add" new files, but once a file is in the repository, any changes
to the file get committed by default (although there are ways to
commit only some files in both Mercurial and SVN and ways to commit
only some changes in Mercurial).
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

But isn't the staging area similar, if not identical to SVN? I mean, in
svn you also have to do a command "svn add" to add new files to the
"sandbox". They won't get commit otherwise, right?
(note: im somewhat familiar with SVN and Git, but not with Mercurial)

No, because in Git if you make changes to an existing file, you
need to "add" that file again. In both SVN or Mercurial, you need to
"add" new files, but once a file is in the repository, any changes
to the file get committed by default (although there are ways to
commit only some files in both Mercurial and SVN and ways to commit
only some changes in Mercurial).
Jerome

I see. Well, it's not identical then, but still, it seems very similar,
since one can use "git commit -a" to do the same as "svn commit", isn't
that so? I mean, is there any aspect to Git's staging area that makes
"git commit -a" not be equivalent to "svn commit" ? (obviously for this
question interactions with Git-only features should not be considered)
My confusion here stems not so much from the discussion in this thread,
but from another discussion elsewhere on the web (not D related) where I
also saw a developer comment that Git's staging index default behavior
was more complex that necessary, and that it should be the simple thing
by default. There was an implication, from the way he said it, that this
was an issue of at least medium importance.
However, from my understanding, in the whole landscape of version
control issues and comparisons, this one seems of very low importance,
if not borderline irrelevance. Because even if a developer using Git
shoots himself in the foot with this... it will be only *once*, on the
learning phase. After that you'd know and remember to use "git commit
-a" so the mistake would not be repeated. A /one-time issue/ cannot
possibly be anywhere near in importance than a /many-times issue/.
--
Bruno Medeiros - Software Engineer

But isn't the staging area similar, if not identical to SVN? I mean, =

in

svn you also have to do a command "svn add" to add new files to the
"sandbox". They won't get commit otherwise, right?
(note: im somewhat familiar with SVN and Git, but not with Mercurial)=

No, because in Git if you make changes to an existing file, you
need to "add" that file again. In both SVN or Mercurial, you need to
"add" new files, but once a file is in the repository, any changes
to the file get committed by default (although there are ways to
commit only some files in both Mercurial and SVN and ways to commit
only some changes in Mercurial).
Jerome

=20
I see. Well, it's not identical then, but still, it seems very similar,=

since one can use "git commit -a" to do the same as "svn commit", isn't=

that so? I mean, is there any aspect to Git's staging area that makes
"git commit -a" not be equivalent to "svn commit" ? (obviously for this=

question interactions with Git-only features should not be considered)
=20
=20
My confusion here stems not so much from the discussion in this thread,=

but from another discussion elsewhere on the web (not D related) where =

I

also saw a developer comment that Git's staging index default behavior
was more complex that necessary, and that it should be the simple thing=

by default. There was an implication, from the way he said it, that thi=

s

was an issue of at least medium importance.
However, from my understanding, in the whole landscape of version
control issues and comparisons, this one seems of very low importance,
if not borderline irrelevance. Because even if a developer using Git
shoots himself in the foot with this... it will be only *once*, on the
learning phase. After that you'd know and remember to use "git commit
-a" so the mistake would not be repeated. A /one-time issue/ cannot
possibly be anywhere near in importance than a /many-times issue/.
=20
=20

Ah, but it is a many-times issue. It is even an every-times issue.
The problem here is that you need to remember to add the appropriate
option each and every time you want to commit. Proper interface
design would be to have the common usage be the default and have an
option to enable the complex usage (especially for the most common
command).
Additionally this makes it a lot more difficult to move back and
forth between several systems: imagine if all VCSes required special
options to do a simple commit, now each time you want to commit, you
need to remember whether this particular VCS requires an option and
which option you need to add to get the simple behaviour.
Moreover, this is just the tip of the iceberg. The whole git UI is
"designed" like that and full of small irritations and inconsistencies.
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

But isn't the staging area similar, if not identical to SVN? I mean, in
svn you also have to do a command "svn add" to add new files to the
"sandbox". They won't get commit otherwise, right?
(note: im somewhat familiar with SVN and Git, but not with Mercurial)

No, because in Git if you make changes to an existing file, you
need to "add" that file again. In both SVN or Mercurial, you need to
"add" new files, but once a file is in the repository, any changes
to the file get committed by default (although there are ways to
commit only some files in both Mercurial and SVN and ways to commit
only some changes in Mercurial).
Jerome

I see. Well, it's not identical then, but still, it seems very similar,
since one can use "git commit -a" to do the same as "svn commit", isn't
that so? I mean, is there any aspect to Git's staging area that makes
"git commit -a" not be equivalent to "svn commit" ? (obviously for this
question interactions with Git-only features should not be considered)
My confusion here stems not so much from the discussion in this thread,
but from another discussion elsewhere on the web (not D related) where I
also saw a developer comment that Git's staging index default behavior
was more complex that necessary, and that it should be the simple thing
by default. There was an implication, from the way he said it, that this
was an issue of at least medium importance.
However, from my understanding, in the whole landscape of version
control issues and comparisons, this one seems of very low importance,
if not borderline irrelevance. Because even if a developer using Git
shoots himself in the foot with this... it will be only *once*, on the
learning phase. After that you'd know and remember to use "git commit
-a" so the mistake would not be repeated. A /one-time issue/ cannot
possibly be anywhere near in importance than a /many-times issue/.

Ah, but it is a many-times issue. It is even an every-times issue.
The problem here is that you need to remember to add the appropriate
option each and every time you want to commit. Proper interface
design would be to have the common usage be the default and have an
option to enable the complex usage (especially for the most common
command).
Additionally this makes it a lot more difficult to move back and
forth between several systems: imagine if all VCSes required special
options to do a simple commit, now each time you want to commit, you
need to remember whether this particular VCS requires an option and
which option you need to add to get the simple behaviour.
Moreover, this is just the tip of the iceberg. The whole git UI is
"designed" like that and full of small irritations and inconsistencies.
Jerome

Well, yes, it is every-times with regards to having to add the extra
commit option. But it is just 3 extra characters, and I'm guessing it is
quite easy to remember every time (maybe a little bit less if you use
different VCS often, yeah).
I'm not saying git would not be better designed if " -a" was the
default, just that it's a very unimportant in terms of comparing VCS's.
(It matters even less to my usage of VCS, since almost always I use
Eclipse's graphical interface, which has a common behavior for the basic
operations in all popular VCS. :) )
--
Bruno Medeiros - Software Engineer

Well, yes, it is every-times with regards to having to add the extra
commit option. But it is just 3 extra characters, and I'm guessing it i=

s

quite easy to remember every time (maybe a little bit less if you use
different VCS often, yeah).
I'm not saying git would not be better designed if " -a" was the
default, just that it's a very unimportant in terms of comparing VCS's.=

(It matters even less to my usage of VCS, since almost always I use
Eclipse's graphical interface, which has a common behavior for the basi=

c

operations in all popular VCS. :) )
=20

Like I said, it is a pretty minor issue in and of itself. Its
importance is as a symptom of how poorly designed the interface is
in general. My main objections to Git are in order of importance:
1. Data corruption on Windows. That one is the killer issue;
2. Poor interface by design! The "-a" option is in this category,
but it is not the only issue there by far. Most of those issues
taken individually would be pretty minor, but added together they
make Git very uncomfortable to work with;
3. Git is not a VCS so much as a PMS (Patch Management System). The
difference is in the way each views history: for a VCS, history is
important in and of itself, whereas for a PMS like Git history is
just something you keep to help you merge branches. Git's much
touted history rewriting abilities are more a liability than an
asset for a VCS. In a roundabout way, this is why most Git users
view the "-a" issue as negligible: if you forget part of a commit,
just commit the missing changes and collapse the two changesets
(which is easy since we don't care about history anyway).
Points 1 and 2 are real issues. That is, they are intrinsically
negative points. Point 3 is more a difference between Git and
everything else, so it will be negative or neutral (*) depending on
what exactly you expect from a SCM.
Jerome
(*) I wrote "neutral" instead of "positive", because IMO Mercurial
offers similar abilities as a PMS if that is all you want.
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

J=C3=A9r=C3=B4me> 3. Git is not a VCS so much as a PMS (Patch Management
J=C3=A9r=C3=B4me> System).The difference is in the way each views history: =
for a
J=C3=A9r=C3=B4me> VCS, history is important in and of itself, whereas for a=
PMS
J=C3=A9r=C3=B4me> like Git history is just something you keep to help you m=
erge
J=C3=A9r=C3=B4me> branches.
=20
I agree (coming from darcs world) and just switched to Fossil which is
very nice keeping 'artifacts' immutable. Something for D. :-)
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

Well, yes, it is every-times with regards to having to add the extra
commit option. But it is just 3 extra characters, and I'm guessing it is
quite easy to remember every time (maybe a little bit less if you use
different VCS often, yeah).
I'm not saying git would not be better designed if " -a" was the
default, just that it's a very unimportant in terms of comparing VCS's.
(It matters even less to my usage of VCS, since almost always I use
Eclipse's graphical interface, which has a common behavior for the basic
operations in all popular VCS. :) )

Like I said, it is a pretty minor issue in and of itself. Its
importance is as a symptom of how poorly designed the interface is
in general. My main objections to Git are in order of importance:
1. Data corruption on Windows. That one is the killer issue;
2. Poor interface by design! The "-a" option is in this category,
but it is not the only issue there by far. Most of those issues
taken individually would be pretty minor, but added together they
make Git very uncomfortable to work with;
3. Git is not a VCS so much as a PMS (Patch Management System). The
difference is in the way each views history: for a VCS, history is
important in and of itself, whereas for a PMS like Git history is
just something you keep to help you merge branches. Git's much
touted history rewriting abilities are more a liability than an
asset for a VCS. In a roundabout way, this is why most Git users
view the "-a" issue as negligible: if you forget part of a commit,
just commit the missing changes and collapse the two changesets
(which is easy since we don't care about history anyway).
Points 1 and 2 are real issues. That is, they are intrinsically
negative points. Point 3 is more a difference between Git and
everything else, so it will be negative or neutral (*) depending on
what exactly you expect from a SCM.
Jerome
(*) I wrote "neutral" instead of "positive", because IMO Mercurial
offers similar abilities as a PMS if that is all you want.

Hum, thanks, this post was quite informative.
But what exactly is that data corruption issue on Windows?
--
Bruno Medeiros - Software Engineer

"add + commit" is not a bad design at all. It is just design choice,
and it also about "patch control system", that allows more logical
commit history and more precise control over VCS. It allows to code
all things you want and place into commit only part of your changes.
You even can stage part of file - if, for example, you done two
logically different changes without commit between them. May be, good
analogy will be reading file with one command versus "open-read-close"
sequence - simplicity versus good control.
This feature allows very comfortable, free coding style - you write
what you want ad understand now, and later you can divide your changes
to logically related sets. You do not controlled by limits imposed by
VCS - "work on one feature, commit, work on another". Instead VCS
works in your style and rhythm. Usually you don't want run "commit
-a". Instead when you run "git status" you see several files that you
do not want to commit right now. So you use "add + commit" sequence,
may be - several times to commit different changesets as distinct
entities with distinct comments.
I think it's very good point of view - to track not file versions,
patchsets that represent something meaningful - new features, bugfixes
etc, and have VCS follow your practices and rhythm - and have
understandable version tree at the end.

"add + commit" is not a bad design at all. It is just design choice,
and it also about "patch control system", that allows more logical
commit history and more precise control over VCS. It allows to code
all things you want and place into commit only part of your changes.
You even can stage part of file - if, for example, you done two
logically different changes without commit between them. May be, good
analogy will be reading file with one command versus "open-read-close"
sequence - simplicity versus good control.
=20
This feature allows very comfortable, free coding style - you write
what you want ad understand now, and later you can divide your changes
to logically related sets. You do not controlled by limits imposed by
VCS - "work on one feature, commit, work on another". Instead VCS
works in your style and rhythm. Usually you don't want run "commit
-a". Instead when you run "git status" you see several files that you
do not want to commit right now. So you use "add + commit" sequence,
may be - several times to commit different changesets as distinct
entities with distinct comments.
=20
I think it's very good point of view - to track not file versions,
patchsets that represent something meaningful - new features, bugfixes
etc, and have VCS follow your practices and rhythm - and have
understandable version tree at the end.

This has nothing to do with Git's staging area. Mercurial also
tracks patchsets that represent something meaningful and has full
support for partial commits (with record or crecord) so you can
"write what you want and understand now, and later [...] divide your
changes to logically related sets". On the other hand, you are not
forced into this model when you know you have only worked on a
single feature and want to commit it.
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

[…] you are not
forced into this model when you know you have only worked on a
single feature and want to commit it.

You are not forced to use the staging area with Git either (although
most of the developers I know do use it), it's just the default that is
different.
If you want to save the extra characters per commit, just add an alias
like »ci = commit -a« to your ~/.gitconfig, just like you might want to
use »nudge = push --rev .« with Mercurial…

In some cases (I didn't try to isolate the precise conditions), Git
will replace '\n' with '\r\n' in binary files. This is with the
default config. It might be possible to change the configuration so
that this won't happen, but the simple fact that this happens with
the *default* config does not fill me with confidence regarding data
integrity and Git...
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

[…]It might be possible to change the configuration so
that this won't happen, but the simple fact that this happens with
the *default* config does not fill me with confidence regarding data
integrity and Git...

This is not exactly true, at least not for the Git on Windows installer,
which presents you with the three possible choices for handling line
endings.
Also, I am not quite sure if this deserves the label »data corruption«,
because even if you have auto-conversion of line endings turned on and
Git fails to auto-detect a file as binary, no history data is corrupted
and you can fix the problem by just switching off auto-conversion
(either globally or just for the file in question via gitattributes) –
in contrast to actual history/database corruption.

[=E2=80=A6]It might be possible to change the configuration so
that this won't happen, but the simple fact that this happens with
the *default* config does not fill me with confidence regarding data
integrity and Git...

=20
This is not exactly true, at least not for the Git on Windows installer=

,

which presents you with the three possible choices for handling line
endings.
=20

Yes, I saw this option and left the default selected.

Also, I am not quite sure if this deserves the label =C2=BBdata corrupt=

ion=C2=AB,

because even if you have auto-conversion of line endings turned on and
Git fails to auto-detect a file as binary, no history data is corrupted=

and you can fix the problem by just switching off auto-conversion
(either globally or just for the file in question via gitattributes) =E2=

=80=93

in contrast to actual history/database corruption.

It deserves the label "data corruption" since Git did the
conversion when committing the file, which means that the version
stored in the history was corrupted.
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

It deserves the label "data corruption" since Git did the
conversion when committing the file, which means that the version
stored in the history was corrupted.

Okay, so you I guess you were pretty unlucky since after you turned the
feature on, Git promptly misdetected one of your files, and you didn't
notice that when you committed your changes – if you had looked at the
diff for whatever reason, you would have probably noticed that something
is wrong (I have this habit of briefly looking what I am checking in,
but that's probably from my SVN-based OSS work).
I don't really know if there is anything that can be done about this
though – in fact Git developers are asked to turn the feature on by
default for usability reasons quite regularly, if I remember correctly.
What certainly could be done is improving the auto detection algorithms,
but that would be an issue for the Git ML/bug tracker.
In any case, you might be interested in the fact that Mercurial seems to
have real issues with data corruption on Windows, see for example the
following reports:
http://serverfault.com/questions/91681/mercurial-repository-corruptionhttp://stackoverflow.com/questions/2563178/corrupt-mercurial-repository-cannot-update

It deserves the label "data corruption" since Git did the
conversion when committing the file, which means that the version
stored in the history was corrupted.

=20
Okay, so you I guess you were pretty unlucky since after you turned the=

feature on, Git promptly misdetected one of your files, and you didn't
notice that when you committed your changes =E2=80=93 if you had looked=

at the

diff for whatever reason, you would have probably noticed that somethin=

g

is wrong (I have this habit of briefly looking what I am checking in,
but that's probably from my SVN-based OSS work).
=20

One of the point here is that I didn't "turn the feature on". It
was turned on by default. Moreover, the first time it happened, I
was importing data from SVN so I didn't look at all the diffs (the
next time it happened, I was adding a new file, so I didn't go
through the whole diff and didn't notice the difference).

In any case, you might be interested in the fact that Mercurial seems t=

Well, at least the second one looks like the user removed some
files from the .hg repository (by recursively removing all files
whose name fit a certain pattern). This kind of mistake would affect
Git too (or any system where the repository is located alongside the
sources).
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

In some cases (I didn't try to isolate the precise conditions), Git
will replace '\n' with '\r\n' in binary files. This is with the
default config. It might be possible to change the configuration so
that this won't happen, but the simple fact that this happens with
the *default* config does not fill me with confidence regarding data
integrity and Git...
Jerome

Hum, my impression is that Git is actually pretty mindful about data
integrity, not just on history, but on commits as well. However, it also
seems like Git was designed with Linux in mind, so Git on Windows is
kinda like a second-class platform (for example, performance is
apparently lower on Windows). But hopefully that will improve on the future.
The comments above made tip my preference slightly over to Mercurial.
But I think ultimately the decision of whether I would use Mercurial or
Git would be decided more by external factors, like the quality of
IDE-integrated tools (read: Eclipse plugins), and the availability or
preference of those DVCS in hosting-sites/organizations. For example
Google Code only supports Mercurial. On the other hand the Eclipse
Foundation is moving their repositories to Git. (if it wasn't for that
I'd likely have gone with Mercurial and not looked back on Git)
--
Bruno Medeiros - Software Engineer

Hum, my impression is that Git is actually pretty mindful about data
integrity, not just on history, but on commits as well. However, it als=

o

seems like Git was designed with Linux in mind, so Git on Windows is
kinda like a second-class platform (for example, performance is
apparently lower on Windows). But hopefully that will improve on the
future.
=20

Performance was actually horrendous on windows last year, not just
"lower".

The comments above made tip my preference slightly over to Mercurial.
But I think ultimately the decision of whether I would use Mercurial or=

Git would be decided more by external factors, like the quality of
IDE-integrated tools (read: Eclipse plugins), and the availability or
preference of those DVCS in hosting-sites/organizations. For example
Google Code only supports Mercurial. On the other hand the Eclipse
Foundation is moving their repositories to Git. (if it wasn't for that
I'd likely have gone with Mercurial and not looked back on Git)
=20

I don't know how good it is, but I believe there is an Eclipse
plugin for Mercurial.
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

=20
That's what you say.
=20
I say that I've been happily using Git on Windows for over two years
without noticing any performance problems.
=20
Now what?

Well, I went back to the message I posted at the time (on June 6
2009 in digitalmars.D) and I need to amend that: "git clone"
performance is horrendous (more than 4 times slower than Mercurial).
Other commands are generally slightly slower than Mercurial but
acceptable, except import from SVN which took several hours for Git
and 5min for Mercurial (but that is not too important since you
don't import from SVN every day, clone performance is a lot more
problematic IMO).
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Well, I went back to the message I posted at the time (on June 6
2009 in digitalmars.D)=20

Sorry, that should read on June *3*. The thread subject was "Re:
Source control for all dmd source (Git propaganda =3D)" if you want to
look it up.
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

project where community involvement is important. For example, I think =

=20

that moving DMD/Phobos/DRuntime from SVN to Bazaar/Monotone/DARCS would b=

e =20

a very bad idea (and I think that GitHub's featureset would fit D's =20
community perfectly).

Moving to any of Bazaar, Mercurial or Git would be a huge step forward
for any FOSS project currently using Subversion. Monotone and Darcs
would be a big risk because Bazaar, Mercurial and Git are the main
players.
Staying with Subversion acts as a barrier to development effort by
anyone other than the Subversion committers. Even if the bzr-svn,
hgsubversion or git-svn plugins are used to bridge from a central
Subversion repository, the barriers are just too high to allow for ad
hoc contribution. So if a project wishes to enforce the "us and them"
partitioning of the community then fine stay with Subversion. If the
idea is to allow for a widening of the active contributor base then a
move to a DVCS is an enabling step.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

Russel> Moving to any of Bazaar, Mercurial or Git would be a huge step
Russel> forward for any FOSS project currently using Subversion.
+1
Russel> Monotone and Darcs would be a big risk because Bazaar,
Russel> Mercurial and Git are the main players.
I agree...I just mentioned them since I am using them for personal
stuff.
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

I quite like GitHub for when I use Git, but I like Launchpad for when I
use Bazaar, or BitBucket for Mercurial -- and of course I host things on
my own server, which means Bazaar or Mercurial or sometimes Git. It
more about what the group of activists on a project choose to use, there
are no absolutes.=20
Git and GitHub are not special in any of the above points. DVCS and
hosting is the underlying model and all the above mentioned have the
basic model. Everything else is really just "little things".
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

Any FOSS project allows this, you just want to use a hosting site.
Launchpad and BitBucket behave like GitHub in this respect -- I don't
know about Gitorious but I suspect it is the same.

I would expect nothing less. Human approval of projects in today's
fast-moving world seems like stone-age.

And the difference with others -- except the one-click being replaced by
a command line?

Is this a serious question?
1) You don't need to take care of firewalls or your own hosting server to
publish your changes
2) The repositories are semantically linked
3) Your commits will appear on the project's network graph, allowing
anyone to merge/cherry-pick them

Personal workflow, the model is not special.

If you say so.

Git and GitHub are not special in any of the above points.

Sorry, I disagree. The second best project hosting website that I saw
which allows this kind of implicit interoperability between forks was
Launchpad.
I stand on my point that GitHub would fit D's development model the best
of all other solutions that I noticed. Because D's project maintenance is
not very reliable, anyone can start their own fork and e.g. add certain
patches from Bugzilla. GitHub's network graph gives you the current state
of a project of all its forks at a glance, which is extremely useful, and
the next best thing is Launchpad's list of branches sorted by last
activity.
Disregarding the capabilities of project hosting websites and judging the
tools alone is absurd, IMO (unless your project's intended contributor
audience dislikes project hosting websites as much as you do).
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Vladimir> Could someone please explain to me why is a VCS other than
Vladimir> the three big ones (SVN, Git and HG) is worth using for an
Vladimir> open-source project such as this?
Maybe it's personal preference...I still find darcs' cherry-picking
and it's UI incomparable to the rest.

Leandro> As an ex-darcs user, I sympathize, but Git now have all the
Leandro> cherry-picking capabilities of darcs, and makes darcs looks
Leandro> like a toy. Really. I recommend you to give it a try, give it
Leandro> some time.
For now, Monotone is capable to handle all my needs.
Otoh, Git's UI looks like a mess and, imho, stands too much on the way
and/or allows to shoot one's foot too easily. For me DVCS is just a
tool supposed to the job and not something I like to think too much
about it.
In that light, darcs is (almost) perfect, but after darcs & monotone
I'd use bzr/hg considering I do not have to handle kernel-like sized
projects.
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

Could you give any examples for this?
While I can understand people who think that the raw power Git makes it
too easy to shoot yourself in the foot (I personally don't think so, but
that's a different topic), I guess I don't really see how it would stand
in your way, given that you can do everything you need by just chaining
together a few well-known commands…

klickverbot> Could you give any examples for this?
man git
It's simply too complex with huge command set which makes it too
difficult to understand what's going on 'under the hood'.
klickverbot> While I can understand people who think that the raw power
klickverbot> Git makes it too easy to shoot yourself in the foot (I
klickverbot> personally don't think so, but that's a different topic),
klickverbot> I guess I don't really see how it would stand in your way,
klickverbot> given that you can do everything you need by just chaining
klickverbot> together a few well-known commands=E2=80=A6
It stands in one's way in the sense that it's not easy to know what's
going on. Compare it with e.g. darcs' ui and/or nicely designed
Monotone (Linus would choose it if there had not been performance
issues at that time).
I want that DVCS serves me and not vice versa. :-)
Moreover, I believe that Git is over-hyped mostly due to its performance and
I prefer design over raw speed.
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

Moreover, I believe that Git is over-hyped mostly due to its performanc=

e and

I prefer design over raw speed.
=20

Actually, I believe git is over-hyped because it was initially
written by someone named "Linus Torvalds" (never mind that he
himself called it a dirty hack thrown together in an afternoon and
most emphatically *not* a version control system).
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Moreover, I believe that Git is over-hyped mostly due to its
performance and
I prefer design over raw speed.

Actually, I believe git is over-hyped because it was initially
written by someone named "Linus Torvalds" (never mind that he
himself called it a dirty hack thrown together in an afternoon and
most emphatically *not* a version control system).

Well, then you'll have to blame Junio Hamano for actually turning it into
a VCS that human beings can use. ;)
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Could you give any examples for this?
While I can understand people who think that the raw power Git makes it
too easy to shoot yourself in the foot (I personally don't think so, but
that's a different topic), I guess I don't really see how it would stand
in your way, given that you can do everything you need by just chaining
together a few well-known commands…

Although (as you might have noticed) I prefer Git, I can answer your
question. Examples:
* The innocent-sounding "checkout" command will irreversibly destroy your
work (it's especially destructive if you pass it the name of a directory)
* Operations such as undoing your last commit are too cryptic (git reset
--hard HEAD^)
* Branch commands are clumsy (creating and switching to a new branch in
one command, setting up a tracking branch)
* Pushing requires verbose commands (specifying the remote and branch
name), unless you configure the default remote for the current branch
As you can see, in many places Git is the antithesis to the "Make correct
and common things easy, make shooting yourself in the foot hard"
principle. However, I don't think this is a reason not to use Git for a
public project.
The thing is, if you're an open-source developer with some experience,
you'll already know how to use Git - due to the overwhelming amount of
open-source projects already using it. Once you get used to the
above-mentioned problems (and maybe set up some aliases to work around
them), there really isn't much reason to learn another DVCS for the sake
of a few of Git's shortcomings.
I think that sooner or later, like with most active open-source projects,
the major DVCS implementations (including Git) will converge to a high
level of stability and usability (git was much harder to use in the past,
so I don't see why the above-mentioned problems won't be fixed in future
major versions as well). At that point there'll be fewer factors to take
into account when choosing a VCS: design, performance(?) and, of course,
popularity.
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Sorry, that's probably a bad example, since it alters history (if you
already pushed the current commit it'll cause problems). The "problem"
with Git is that you really need to know what you're doing and how things
work behind the scenes - the learning curve is pretty steep, however once
you're over it you'll feel like King of the Hill compared to other DVCSes
:)
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

Vladimir> As you can see, in many places Git is the antithesis to the
Vladimir> "Make correct and common things easy, make shooting yourself
Vladimir> in the foot hard" principle. However, I don't think this is a
Vladimir> reason not to use Git for a public project.
What about 'choice' or maybe we should move to the OS used by majority
of people where re-installation is very common troubleshooting
procedure? ;)
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

A good analogy is writing software only for Linux, because the major OS
is so horrible.

For what it's worth, I never had any problems with my Windows install -
the only time I reinstalled was when I upgraded to newer versions (and I
do that when I upgrade my hardware, incl. HDDs, anyway).
From my experience of troubleshooting others' Windows computers, all the
breakages come from badly-written applications (and installers), which
overwrite system files or (sometimes forcibly) integrate themselves into
every corner of the operating system, causing instability etc. This isn't
a problem with Windows - its "problem" is that it's the most popular OS,
for which so much bad software is written (not to mention malware).
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

A good analogy is writing software only for Linux, because the major OS
is so horrible.

For what it's worth, I never had any problems with my Windows install -
the only time I reinstalled was when I upgraded to newer versions (and I
do that when I upgrade my hardware, incl. HDDs, anyway).
From my experience of troubleshooting others' Windows computers, all the
breakages come from badly-written applications (and installers), which
overwrite system files or (sometimes forcibly) integrate themselves into
every corner of the operating system, causing instability etc. This isn't
a problem with Windows - its "problem" is that it's the most popular OS,
for which so much bad software is written (not to mention malware).

Don't forget drivers. Half the time it seems like there isn't a single
hardware manufacturer that actually knows what they're doing when it comes
to writing Windows drivers.

=20
Could someone please explain to me why is a VCS other than the three big =

=20

ones (SVN, Git and HG) is worth using for an open-source project such as =

=20

this?

Because it is good. Because there are four major players in the game,
including Bazaar.

I have never used Bazaar, DARCS and Monotone, and only briefly used HG, =

=20

and I acknowledge that they may be better than Git in some aspects. =20

They are, but the problem is that currently there is no scientific and
objective data, all views on this are opinion and adherence to either
fashion or tribalism.

However, IMHO, one of the main decisions for a VCS for a public project i=

s =20

its accessibility. SVN is the most popular one, but it's pretty =20
established that SVN isn't anywhere as productive as DVCSes, and obviousl=

y =20

it can't be used in a distributed manner.

The only sensible use for Subversion in a FOSS project is not to use it.
Bazaar, Mercurial and Git are the VCS tools for FOSS projects. Why?
Because DVCS aligns with the principles of FOSS. Subversion is all
about creating an elite priesthood.
Subversion is fine is a context where the entire developer population
have access and are permanently connected to the Internet and are only
allowed to work when so connected -- i.e. in companies where no working
outside the "boundary fence" is allowed. But the FOSS community has
outgrown the Subversion model.
=20

If I'd consider contributing to an open-source project using a VCS I'm =

=20

unfamiliar with, it's quite likely that I'd get turned off by the hurdle =

=20

of downloading, installing and learning to use the respective VCS.

It's not the downloading that is the problem so much as the unfamiliar
with.

Russel wrote in another, unrelated thread:

Of course using BitBucket or Launchpad may well be more likely to get
support as Mercurial and Bazaar are so much more usable that Git.

=20
I'm sorry, but to me that sounds like a biased personal opinion stated as=

=20

if it was an objective fact :( I seriously doubt that any project would =

=20

get more "support" if it used an obscure (albeit possibly better in some =

already familiar with that DVCS. Maybe Bazaar etc. is more popular with =

=20

EMACS users/hackers?

I'll accept that there is an element of personal opinion -- I believe
that Git is over-complicated both in operational model and command line.
Bazaar and Mercurial beat Git hand down in my usability. As noted above
no-one to date has objective data so all statements on this are opinion.
This includes your view on Git :-)
I wouldn't say Bazaar was more popular with the Emacs developers, there
was a huge row about it and there are still rumblings. However Bazaar
is the official VCS for Emacs.

For personal individual working GitHub is fine. However, as far as I
know, it has no notion of team. Launchpad has both the notion of
personal and of team. For uncontrolled FOSS this perhaps doesn't
matter, but it makes it a lot easier to actually emulate the high priest
elite that many project like to have.=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

For personal individual working GitHub is fine. However, as far as I
know, it has no notion of team. Launchpad has both the notion of
personal and of team. For uncontrolled FOSS this perhaps doesn't
matter, but it makes it a lot easier to actually emulate the high priest
elite that many project like to have.

FWIW: GitHub recently introduced an "organizations" feature, which might
be close to the "team" notion you describe.
I didn't consider Bazaar a "major player" because I only heard of a few
projects using it.
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

I agree completely with your rankings of the tools, I just come down on the
side of Mercurial rather than Bazaar.
I don't really like how Bazaar tries to support multiple workflows. (
http://wiki.bazaar.canonical.com/Workflows)
I prefer the simplicity of Mercurial's approach. It doesn't ask you to
first figure out how you're going to be using the repository. Bazaar's
approach reminds me of doing object-oriented programming in lisp or lua or
javascript. "It's so flexible!" they say. "You can implement classes and
inheritance in all these different ways!" Bleh. Just give me one that
works well and don't make me spend my time on such low-level decisions.
But Bazaar would be my #2 choice after Mercurial. It's certainly better
than most.
--bb
On Mon, Oct 25, 2010 at 11:42 AM, Russel Winder <russel russel.org.uk>wrote:

On Mon, 2010-10-25 at 10:20 -0700, Bill Baxter wrote:

I'm not a huge fan of Bazaar :-p ,

Hummm... May I ask why?
Personally I think Bazaar, Mercurial and Git beat Subversion, CVS,
ClearCase, TFS, etc. always. Moreover Bazaar and Mercurial beat Git.
Overall I see two different best cases for Bazaar and Mercurial --
basically when it is important for file hierarchy to be a branch vs
having everything all in one repository.

but thanks for putting it up somewhere more amenable to collaborative
revisioning than the wiki where it was!
I'll take Bazaar over a bizarre wiki interface any day.

Bill> I agree completely with your rankings of the tools, I just come
Bill> down on the side of Mercurial rather than Bazaar.
Let me just say that after using darcs for many years as my primary
dvcs, now I moved to Monotone which will soon be supported by
e.g. indefero.net hosting.
Otoh, I like both bzr & hg as long it's not named 'git'. :-)
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

Russel> It's only me just now, but hopefully there are other Emacs
Russel> users and ELisp capable people who will volunteer to join in so
Russel> there is a community that can ensure progress.
I'm an Emacs user, but not Elisp-capable person, so I am not certain
whether it makes sense to join?
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------

I'm an Emacs user, but not Elisp-capable person, so I am not certain
whether it makes sense to join?

I think members of the team really need to be E-Lisp capable and
prepared to amend and test the code. But I say this with some caution
as it is important to have people willing to test, even if they are not
able to amend themselves.
I guess what is needed is some form of email list for everyone who uses
the mode to create the community with active amenders of the code being
members of the management team.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

Russel> I guess what is needed is some form of email list for everyone
Russel> who uses the mode to create the community with active amenders
Russel> of the code being members of the management team.
OK. I agree, so I will restrain myself from joining and will wait for
some email list to emerge.
Sincerely,
Gour
--=20
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
----------------------------------------------------------------