www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Emacs D Mode now on Launchpad

reply Russel Winder <russel russel.org.uk> writes:
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
Oct 24 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/25/10 1:32 CDT, Russel Winder wrote:
 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.
Thanks! I just tendered my candidature :o). Andrei
Oct 25 2010
next sibling parent Russel Winder <russel russel.org.uk> writes:
On Mon, 2010-10-25 at 11:29 -0500, Andrei Alexandrescu wrote:
[ . . . ]
 Thanks! I just tendered my candidature :o).
Accepted and voted in. :-) --=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
Oct 25 2010
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
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:

 On Mon, 2010-10-25 at 11:29 -0500, Andrei Alexandrescu wrote:
 [ . . . ]
 Thanks! I just tendered my candidature :o).
Accepted and voted in. :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net <sip%3Arussel.winder ekiga.net> 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
Oct 25 2010
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
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.=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.
:-) No problem. I have this hatred of source code being stored on wikis as both the SCons and D communities now know :-) --=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
Oct 25 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 25 Oct 2010 21:42:32 +0300, 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?
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
Oct 27 2010
next sibling parent reply Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 12:02:06 +0300
 "Vladimir" =3D=3D <vladimir thecybershadow.net> wrote:
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 ----------------------------------------------------------------
Oct 27 2010
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 12:31:49 +0300, Gour <gour atmarama.net> wrote:

 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
Oct 27 2010
next sibling parent reply Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 12:56:51 +0300
 "Vladimir" =3D=3D "Vladimir Panteleev" wrote:
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 ----------------------------------------------------------------
Oct 27 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 13:58:56 +0300, Gour <gour atmarama.net> wrote:


 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
Oct 27 2010
parent reply Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 14:36:47 +0300
 "Vladimir" =3D=3D <vladimir thecybershadow.net> wrote:
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 ----------------------------------------------------------------
Oct 27 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 16:07:52 +0300, Gour <gour atmarama.net> wrote:

 Try https://code.launchpad.net/bzr
Ah, that's quite nice.
 Well, it's question of bitbucket's interface, nothing about git.
And I wasn't talking about Git by itself. If you look at http://whygitisbetterthanx.com/ , GitHub is listed as one of the major reasons.
 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
Oct 27 2010
next sibling parent Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 17:25:35 +0300
 "Vladimir" =3D=3D <vladimir thecybershadow.net> wrote:
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 ----------------------------------------------------------------
Oct 27 2010
prev sibling next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Vladimir Panteleev wrote:
 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
OTOH, Bazaar *is* one of the mainstream DVCSs (along with SVN, Mercurial and Git). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 27 2010
parent reply klickverbot <see klickverbot.at> writes:
On 10/27/10 7:40 PM, "Jérôme M. Berger" wrote:
 	OTOH, Bazaar *is* one of the mainstream DVCSs (along with SVN,
 Mercurial and Git).
I guess it's not really representative (nor scientific, of course), but here are a few numbers: http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend http://www.ohloh.net/repositories/compare
Oct 27 2010
next sibling parent reply Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 20:37:58 +0200
 "klickverbot" =3D=3D klickverbot wrote:
klickverbot> I guess it's not really representative (nor scientific, of klickverbot> course), but here are a few numbers: Ahh, statistics...I'm the one in 5.14% minority class: http://tinyurl.com/y5bzcfh :-) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 27 2010
parent "Nick Sabalausky" <a a.a> writes:
"Gour" <gour atmarama.net> wrote in message 
news:20101027210750.616814d0 atmarama.noip.me...
Ahh, statistics...I'm the one in 5.14% minority class:

http://tinyurl.com/y5bzcfh
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?
Oct 27 2010
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 21:37:58 +0300, klickverbot <see klickverbot.at> wrote:

 http://www.ohloh.net/repositories/compare
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
Oct 27 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Vladimir Panteleev wrote:
 On Wed, 27 Oct 2010 21:37:58 +0300, klickverbot <see klickverbot.at> wr=
ote:
=20
 http://www.ohloh.net/repositories/compare
=20 Woah! I knew Hg's user base was smaller than Git's, but I never expecte=
d
 the difference to be so huge. That removes any doubt I had whether to
 consider Hg for any of my own projects.
=20
However, count on having trouble if you plan to use git on Windows (including data loss and data corruption)... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 27 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 22:54:59 +0300, Jérôme M. Berger <jeberger free.fr>  
wrote:

 	However, count on having trouble if you plan to use git on Windows
 (including data loss and data corruption)...
I use Git on Windows. Never had any problems. :D Yes, I know Git was bad on Windows. Was :) -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Oct 27 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Vladimir Panteleev wrote:
 On Wed, 27 Oct 2010 22:54:59 +0300, J=C3=A9r=C3=B4me M. Berger <jeberge=
r free.fr>
 wrote:
=20
     However, count on having trouble if you plan to use git on Windows=
 (including data loss and data corruption)...
=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
Oct 27 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 23:29:02 +0300, Jérôme M. Berger <jeberger free.fr>  
wrote:

 	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
Oct 27 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Vladimir Panteleev wrote:
     Anyway, I don't see any point in using Git since Mercurial can syn=
c
 just fine with a Git repository :)
=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
Oct 27 2010
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 00:33:54 +0300, Jérôme M. Berger <jeberger free.fr>  
wrote:

 	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;
For the record, I wish I had found this earlier: http://eagain.net/articles/git-for-computer-scientists/ For a long time I was confused about what branches and tags really are.
 - 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
Oct 27 2010
next sibling parent reply Gour <gour atmarama.net> writes:
On Thu, 28 Oct 2010 08:17:02 +0300
 "Vladimir" =3D=3D <vladimir thecybershadow.net> wrote:
Vladimir> 2) Fire up git gui git and gui? Come on... Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Oct 27 2010
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 08:40:56 +0300, Gour <gour atmarama.net> wrote:

 git and gui? Come on...
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
Oct 27 2010
prev sibling parent Uno <unodgs tlen.pl> writes:
 git and gui? Come on...
Have you seen this: http://www.syntevo.com/smartgit/index.html ?
Oct 28 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Vladimir Panteleev wrote:
 On Thu, 28 Oct 2010 00:33:54 +0300, J=C3=A9r=C3=B4me M. Berger <jeberge=
r free.fr>
 wrote:
=20
     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 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 cd .. rm -r myrepo
 - 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
I meant Mercurial repositories are smaller than Git repositories on Windows (didn't check anywhere else)
 - 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
This workflow is fully supported by the crecord extension (or by TortoiseHg). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 28 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 27/10/2010 22:33, "Jérôme M. Berger" wrote:
 	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
Oct 28 2010
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 15:45:08 +0300, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 On 27/10/2010 22:33, "Jérôme M. Berger" wrote:
 	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
Oct 28 2010
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Bruno Medeiros wrote:
 On 27/10/2010 22:33, "J=C3=A9r=C3=B4me M. Berger" wrote:
     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.
=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
Oct 28 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 28/10/2010 18:51, "Jérôme M. Berger" wrote:
 Bruno Medeiros wrote:
 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
Nov 09 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Bruno Medeiros wrote:
 On 28/10/2010 18:51, "J=C3=A9r=C3=B4me M. Berger" wrote:
 Bruno Medeiros wrote:
 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
Nov 10 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 10/11/2010 10:20, "Jérôme M. Berger" wrote:
 Bruno Medeiros wrote:
 On 28/10/2010 18:51, "Jérôme M. Berger" wrote:
 Bruno Medeiros wrote:
 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
Nov 11 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Bruno Medeiros wrote:
 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
Nov 13 2010
next sibling parent reply Gour <gour atmarama.net> writes:
On Sat, 13 Nov 2010 12:24:58 +0100
 "J=C3=A9r=C3=B4me" =3D=3D <jeberger free.fr> wrote:
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 ----------------------------------------------------------------
Nov 13 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Gour wrote:
 On Sat, 13 Nov 2010 12:24:58 +0100
 "J=C3=A9r=C3=B4me" =3D=3D <jeberger free.fr> wrote:
=20 J=C3=A9r=C3=B4me> 3. Git is not a VCS so much as a PMS (Patch Managemen=
t
 J=C3=A9r=C3=B4me> System).The difference is in the way each views histo=
ry: for a
 J=C3=A9r=C3=B4me> VCS, history is important in and of itself, whereas f=
or a PMS
 J=C3=A9r=C3=B4me> like Git history is just something you keep to help y=
ou merge
 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. :-)
=20
Nice, I didn't know about Fossil. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Nov 14 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 13/11/2010 11:24, "Jérôme M. Berger" wrote:
 Bruno Medeiros wrote:
 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
Nov 17 2010
next sibling parent reply Alexey Khmara <alex.khmara gmail.com> writes:
"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.
Nov 17 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Alexey Khmara wrote:
 "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
Nov 17 2010
parent klickverbot <see klickverbot.at> writes:
On 11/17/10 10:32 PM, "Jérôme M. Berger" wrote:
 […] 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…
Nov 17 2010
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Bruno Medeiros wrote:
 But what exactly is that data corruption issue on Windows?
=20
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
Nov 17 2010
next sibling parent reply klickverbot <see klickverbot.at> writes:
On 11/17/10 10:27 PM, "Jérôme M. Berger" wrote:
 […]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.
Nov 17 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
klickverbot wrote:
 On 11/17/10 10:27 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:
 [=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
Nov 18 2010
parent reply klickverbot <see klickverbot.at> writes:
On 11/18/10 8:18 PM, "Jérôme M. Berger" wrote:
 	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-corruption http://stackoverflow.com/questions/2563178/corrupt-mercurial-repository-cannot-update
Nov 18 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
klickverbot wrote:
 On 11/18/10 8:18 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:
     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=
o
 have real issues with data corruption on Windows, see for example the
 following reports:
=20
 http://serverfault.com/questions/91681/mercurial-repository-corruption
 http://stackoverflow.com/questions/2563178/corrupt-mercurial-repository=
-cannot-update
=20
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
Nov 18 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 17/11/2010 21:27, "Jérôme M. Berger" wrote:
 Bruno Medeiros wrote:
 But what exactly is that data corruption issue on Windows?
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
Nov 18 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Bruno Medeiros wrote:
 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
Nov 18 2010
parent reply klickverbot <see klickverbot.at> writes:
On 11/18/10 8:20 PM, "Jérôme M. Berger" wrote:
 	Performance was actually horrendous on windows last year, not just
 "lower".
That's what you say. I say that I've been happily using Git on Windows for over two years without noticing any performance problems. Now what?
Nov 18 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
klickverbot wrote:
 On 11/18/10 8:20 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:
     Performance was actually horrendous on windows last year, not just=
 "lower".
=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
Nov 18 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
J=C3=A9r=C3=B4me M. Berger wrote:
 	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
Nov 18 2010
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Wed, 2010-10-27 at 17:25 +0300, Vladimir Panteleev wrote:
[ . . . ]
 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
Oct 28 2010
parent Gour <gour atmarama.net> writes:
On Thu, 28 Oct 2010 08:54:31 +0100
 "Russel" =3D=3D Russel Winder wrote:
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 ----------------------------------------------------------------
Oct 28 2010
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Wed, 2010-10-27 at 12:56 +0300, Vladimir Panteleev wrote:
[ . . . ]
 It's not really about Git, it's about GitHub:
Actually, it is about your use model of GitHub. =20
 1. Repo creation is instant, doesn't need to go through a human approval =
=20
 process, etc. (big turn-off from DSource, SourceForge as I create and wor=
k =20
 on many small projects)
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.
 2. One-click forking - self-explanatory, you get a cheap clone of a =20
 project in your own namespace, to which you can push to to instantly =20
 publish your changes.
And the difference with others -- except the one-click being replaced by a command line?
 3. Pull requests - pretty self-explanatory, but integrated with the issue=
=20
 system.
Personal workflow, the model is not special.
 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. =
=20
 This allows easily finding nice forks to merge / cherry-pick. If you're =
=20
 lazy, you don't even need to send your patches upstream - as long as you =
=20
 don't change the license, the project maintainers can cherry-pick from =
=20
 your fork as long as you push them to your fork. Personally, I think this=
=20
 feature is revolutionary, and quite "hard to beat" compared to the =20
 oldschool approach of mailing lists etc. ;)
=20
 GitHub has other nice things, such as line-level commit comments, as well=
=20
 as the usual things you'll find in many other open-source project hosters=
=20
 (issues, wiki, HTML project homepage).
=20
 And finally, IMHO a pretty convincing argument is that GitHub is one of =
=20
 the most popular open-source hosting websites. Not having to register and=
=20
 familiarize yourself with a project hosting website lowers the =20
 contribution barrier even lower.
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
Oct 28 2010
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 10:48:26 +0300, Russel Winder <russel russel.org.uk>  
wrote:

 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
Oct 28 2010
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Gour, el 27 de octubre a las 11:31 me escribiste:
 On Wed, 27 Oct 2010 12:02:06 +0300
 "Vladimir" == <vladimir thecybershadow.net> wrote:
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.
As an ex-darcs user, I sympathize, but Git now have all the cherry-picking capabilities of darcs, and makes darcs looks like a toy. Really. I recommend you to give it a try, give it some time. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- SEÑOR BIELSA: CON TODO RESPETO ¿USTED LO VE JUGAR A RIQUELME? -- Crónica TV
Oct 27 2010
parent reply Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 12:22:23 -0300
 "Leandro" =3D=3D <luca llucax.com.ar> wrote:
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 ----------------------------------------------------------------
Oct 27 2010
parent reply klickverbot <see klickverbot.at> writes:
On 10/27/10 7:09 PM, Gour wrote:
 Otoh, Git […] stands too much on the way […]
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…
Oct 27 2010
next sibling parent reply Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 20:18:43 +0200
 "klickverbot" =3D=3D klickverbot wrote:
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 ----------------------------------------------------------------
Oct 27 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Gour wrote:
 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
Oct 27 2010
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 22:57:39 +0300, Jérôme M. Berger <jeberger free.fr>  
wrote:

 Gour wrote:
 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
Oct 27 2010
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 21:18:43 +0300, klickverbot <see klickverbot.at> wrote:

 On 10/27/10 7:09 PM, Gour wrote:
 Otoh, Git […] stands too much on the way […]
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
Oct 27 2010
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 27 Oct 2010 23:08:02 +0300, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 * Operations such as undoing your last commit are too cryptic (git reset  
 --hard HEAD^)
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
Oct 27 2010
prev sibling parent reply Gour <gour atmarama.net> writes:
On Wed, 27 Oct 2010 23:08:02 +0300
 "Vladimir" =3D=3D <vladimir thecybershadow.net> wrote:
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 ----------------------------------------------------------------
Oct 27 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 09:26:32 +0300, Gour <gour atmarama.net> wrote:

 What about 'choice' or maybe we should move to the OS used by majority
 of people where re-installation is very common troubleshooting
 procedure?
That's a bad analogy. A good analogy is writing software only for Linux, because the major OS is so horrible. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Oct 28 2010
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 10:25:21 +0300, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

  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
Oct 28 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vk9y2yhztuzx1w cybershadow.mshome.net...
 On Thu, 28 Oct 2010 10:25:21 +0300, Vladimir Panteleev 
 <vladimir thecybershadow.net> wrote:

  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.
Oct 28 2010
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 11:33:40 +0300, Nick Sabalausky <a a.a> wrote:

 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.
Good point. I wonder if Linux allowing proprietary/closed-source drivers is a bad or good thing in the long run. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Oct 28 2010
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Wed, 2010-10-27 at 12:02 +0300, Vladimir Panteleev wrote:
 On Mon, 25 Oct 2010 21:42:32 +0300, Russel Winder <russel russel.org.uk> =
=20
 wrote:
=20
 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?
=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 =
=20
 ways) DVCS, unless the intended audience for the project's contributors i=
s =20
 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.
 Also, I think that it's pretty hard to beat the workflow that GitHub =20
 facilitates for open-source projects (with one-click forking and pull =
=20
 requests).
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
Oct 28 2010
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 28 Oct 2010 10:40:03 +0300, Russel Winder <russel russel.org.uk>  
wrote:

 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
Oct 28 2010
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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.


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.
:-) No problem. I have this hatred of source code being stored on wikis as both the SCons and D communities now know :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net <sip%3Arussel.winder ekiga.net> 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
Oct 25 2010
parent Gour <gour atmarama.net> writes:
On Mon, 25 Oct 2010 12:30:56 -0700
 "Bill" =3D=3D Bill Baxter wrote:
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 ----------------------------------------------------------------
Oct 25 2010
prev sibling next sibling parent reply Gour <gour atmarama.net> writes:
On Mon, 25 Oct 2010 07:32:00 +0100
 "Russel" =3D=3D Russel Winder <russel russel.org.uk> wrote:
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 ----------------------------------------------------------------
Oct 25 2010
parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2010-10-25 at 20:01 +0200, Gour wrote:
[ . . . ]
 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
Oct 25 2010
parent Gour <gour atmarama.net> writes:
On Mon, 25 Oct 2010 19:38:13 +0100
 "Russel" =3D=3D Russel Winder wrote:
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 ----------------------------------------------------------------
Oct 25 2010
prev sibling parent Gareth Charnock <gareth.charnock gmail.com> writes:
As one of those strange creatures who use emacs, I thank you for taking 
this up! Sadly I'm not an elisper but if I find bugs I'll let you know.

On 25/10/10 07:32, Russel Winder wrote:
 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.
Oct 25 2010