From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1J5zij-0001rw-PF for mharc-grub-devel@gnu.org; Sat, 22 Dec 2007 03:28:33 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J5zii-0001px-3H for grub-devel@gnu.org; Sat, 22 Dec 2007 03:28:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J5zih-0001og-5X for grub-devel@gnu.org; Sat, 22 Dec 2007 03:28:31 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J5zig-0001oS-TN for grub-devel@gnu.org; Sat, 22 Dec 2007 03:28:30 -0500 Received: from ns39764.ovh.net ([91.121.25.85] helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J5zig-0005Tw-E4 for grub-devel@gnu.org; Sat, 22 Dec 2007 03:28:30 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 6062F3EB23 for ; Sat, 22 Dec 2007 09:32:23 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sat, 22 Dec 2007 09:28:28 +0100 User-Agent: KMail/1.9.4 References: <1196963148.15804.44.camel@dv> <200712180357.38552.okuji@enbug.org> <8763yww6mc.fsf@lab.ossystems.com.br> In-Reply-To: <8763yww6mc.fsf@lab.ossystems.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712220928.28355.okuji@enbug.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Switching to git? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2007 08:28:32 -0000 On Tuesday 18 December 2007 13:05, Otavio Salvador wrote: > > - All developers are forced to install new software and learn it (always > > a pain). > > Developers are used (or ought to) to learn new things since it's of > programming art. I guess learning wouldn't be a problem. =46rom a theoretical point of view, you're definitely right, but the realit= y=20 looks reverse to me. For instance, look at the inability of developers to=20 editors... Even if Emacs is far superior when writing GNU-style C code, vi= =20 users never try to learn how to use Emacs. When it comes to command-line=20 utilities vs. graphical applications, the situation is even worse. In my experience, (unfortunately) developers are too lazy to change tools.= =20 They change, only when they are forced or excited for some (geeky) reason.= =20 This includes myself. > > - All local (pending) changes in working copies become very hard to mer= ge > > (extremely painful). > > Just a "cvs diff > /tmp/foo ; cd ~/newrepo ; patch -p1 < /tmp/foo" > works for most of cases and then it's not a really big problem from my PO= V. It is a problem. It is catastrophic, especially when an original repository= is=20 down. BTW, I have 4 different working copies of GRUB locally. All of them have=20 small, different changes not committed. Do you think I would be happy to de= al=20 with these changes with a "mostly-working" solution? If I don't see more=20 benefit from migrating to another SCM, I really don't want. > > - It is hard to re-select yet another SCM later, because old software is > > usually better supported for migrations, i.e. it's not cheap to migrate > > back and forth (very painful). > > I guess nobody wants to come back to CVS after getting out from it. You need it, if a new SCM does not have a converter directly. > Agree on that. However since git does offer a CVS server this can be > reduced a lot allowing you and anyother that don't want to move to it > to stay using CVS for hacking. This is nice. > > Ok, now about the git. As Tom=C3=A1=C5=A1 pointed out, the lack of port= ability is > > regression from CVS. If you think, for example, grub4dos is important, > > why can you choose git? > > Agree on that too. > > It's not that bad[1] and users can use git with cygwin or via > git-cvspserver. > > 1. http://git.or.cz/gitwiki/WindowsInstall I can't say if it is good or not, since I myself does not use Windows at al= l=20 these days. I leave the evaluation to someone who uses Windows every day. > While I agree that it's not the best merging algorithm I also fail to > see why it could be a blocker. > > I've been using GIT for a while and I do not see conflicts very > ofthen. Linux kernel also does it and I don't see people complaining > about it. The problem is not conflicts but merging. Usually, people don't understand = the=20 importance, until they get weird merging results, and spend several days on= ly=20 to fix up wrong results. However, if you notice a merging problem, you are= =20 still lucky; in particular when you merge big changes, it is not easy to se= e=20 how merging went well. Sometimes, having conflicts is much better, because= =20 you obtain a chance to see what your SCM thinks. When merging is done=20 silently, and it is wrong, the effort on finding mistakes is tremendous. > Personally I don't like bazaar due performance problem. It's really > slow for big projects (it wouldn't be a big problem since GRUB is a > small one) and it changes its data format too ofthen. Hmm, I thought they have fixed the performance issues already? About the da= ta=20 format, I have no idea. jbailey, do you have any comment? ;) > > If I'd going to choose, I'd go to GIT or Mercurial. Mercurial is not bad, except for the 3-way merging. Okuji