From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21363 invoked by alias); 21 Sep 2009 22:41:42 -0000 Received: (qmail 21350 invoked by uid 22791); 21 Sep 2009 22:41:40 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 22:41:34 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E69182F7801E; Mon, 21 Sep 2009 23:41:31 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2QEV2pvFt0S; Mon, 21 Sep 2009 23:41:26 +0100 (BST) Message-ID: <4AB80124.3080708@ecoscentric.com> Date: Mon, 21 Sep 2009 22:41:00 -0000 From: Alex Schuilenburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Sergei Organov CC: ecos-discuss@sources.redhat.com References: <4AB7900D.30204@ecoscentric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: Switching to using git on eCosForge X-SW-Source: 2009-09/txt/msg00181.txt.bz2 Sergei Organov wrote: > Alex Schuilenburg writes: > [...] > >> My main argument against git is it has a very steep initial learning >> curve, >> > Really? Not in my experience. Yes, really, and not only my experience either. I guess I must be below the curve on learning new technology, but then it could also be my age ;-) > IMHO, those 3 we discuss are roughly the > same, just having raw corners in different places. E.g., there is even a > table of commands equivalence between hg and git somewhere. > Several places actually. And yes, functionality on each is roughly the same. > >> and from experience you can hang yourself if you do not know what >> you are doing. (Yes, there are rollbacks, etc, but sometimes it is a >> while down the line before you realise you did something wrong). >> > > It's a very nice thing with git that it's virtually impossible to loose > your work as soon as you committed it to git, really, even if you keep > doing something wrong. Even though nowadays git does automatically run > garbage collection, the reflog feature still keeps all unreferenced data > intact for rather long time. > > And yes, functionality on each is roughly the same. I think we should stop going round in circles. We appear to agree all three have similar functionality. If you want a contest on which is the most powerful, I will save you the trouble. git is currently the most powerful. If you want an example of a powerful feature git has that is harder to do in the others, let me save you the trouble again: git commit --amend (in hg if the commit is buried you will need to have been using queues and will have to export changesets, fix and re-import - more painful, but achievable). However, I would point out again that all three borrow from the others, so evaluating is always going to be a moving target. >> You really don't want to force new users on an additional learning >> curve. There are 100's of commands to remember, whereas both bzr and >> hg have one. >> > > Come on! Which one? 'hg' and 'bzr'??? Then git surprisingly has only > one as well: 'git' ;-) > > One does need additional learning curve switching from CVS to any of > DVCS'es, and all of them have *-for-CVS-users-manual ;-) And once again, > with git you can have gitcvsserver running to keep "CVS forever" > users happy with their favorite clients. > % ls -l /usr/bin/git-* | wc -l 136 % and I only have git-core installed on that machine... FWIW I already had come upto speed with DRCS with bzr and hg before I played with git. Figuring out which command to use to do a specific task without resorting to a manual was my initial stumbling block - I just initially felt somewhat overwhelmed. bzr and hg seemed easier to pick up and start using where with git I was never quite sure if I was using the correct options. Too many bells and whistles I guess which was compounded by not easily being able to find pointers to assure me I was doing the right thing. Hence I never quite felt comfortable using git in the beginning. But of course this is a subjective opinion - YMMV. >> Also, while documentation is improving (http://book.git-scm.com/), it is >> not as good or complete as mercurial (http://hgbook.red-bean.com/read/) >> in terms of non-power users. Both have books in print available from >> places like Amazon. >> > > For me git's documentation was more than enough to have a quick-start. > > >> For example, I started my evaluation with bzr, then hg then git. bzr and >> hg were a lot easiest to pick up and start using than git. >> > > I wonder, do you remember what the problem(s) with git was (were)? Care > to give an example where git is harder than any of the other two? > I never said I had problems doing things in git - I said I had problems finding out how to do them. Tell me with a straight face that the number of options in some of the git commands did not overwhelm you the first time you saw them? When you want to encourage community development, you really need to keep it simple for developers to keep abreast of advances and contribute back. Not have so many bells and whistles that they feel like they should not touch anything in case it breaks, or worse, have someone who thinks they know what they are doing but does not. > >> I also have done most of my eval on Linux, dropping back to Windows to >> see how easy it was to use and integrate graphical diff tools, etc. >> >> For other comparisons see: >> http://code.google.com/p/support/wiki/DVCSAnalysis >> http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ >> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ >> http://stackoverflow.com/questions/1450348/git-equivalents-of-most-common-mercurial-commands >> http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/ >> http://www.diffen.com/difference/Git_%28software%29_vs_Mercurial_%28software%29 >> ... >> >> but bear in mind that arguments against either git or hg may have >> disappeared with more recent versions. You really need to try both... >> > > Yes, all 3 are improving and do borrow from each other. However, in my > opinion, git is preferred in the long run as it has very clear, simple > yet powerful model in its core, when hg already outlived its initial > simple design model based on "every branch is a separate repository" > idea (now it has 3(!) different kinds of branches), and bzr is being > built from use-cases down (see how many times they have already changed > format of repository). Yes, sure, me could be entirely wrong ;-) > Not entirely wrong ;-) When working with branches ever run "git submodule update" when you've made and committed changes within a submodule without checking out the branch first, only to discover later that the changes were silently overwritten? However, I strongly disagree with your comment "hg already outlived its initial simple design..." though. hg's design is just as simple as git and there is nothing in hg's design IMHO that limits what it can do. It is still evolving, just like git and eCos. The forests extension has been around just as long as sub-modules AFAIKT, but I admit it is taking a while for hg to make it part of their core functionality. I am sure we can equally find flaws in the others preferred DRCS just as we can find features... And defintely yes, all three borrow from each other, even documentation in the case of git ;-) http://cworth.org/hgbook-git/tour/). But IMHO hg still has stronger documentation and is easier for newcomers to start with. Anyway, it is good to have an alternative view on what the best choice of DRCS for eCos is. I guess you and I can agree to disagree on what that choice should be though, and let others tell us what they think ;-) -- Alex Schuilenburg >>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<< >>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<< >>>> Visit us at ESC-UK http://www.embedded.co.uk <<<< >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<< -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss