From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1J604P-0002c4-3X for mharc-grub-devel@gnu.org; Sat, 22 Dec 2007 03:50:57 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J604M-0002bP-Sc for grub-devel@gnu.org; Sat, 22 Dec 2007 03:50:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J604L-0002bD-Ah for grub-devel@gnu.org; Sat, 22 Dec 2007 03:50:53 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J604L-0002bA-5E for grub-devel@gnu.org; Sat, 22 Dec 2007 03:50:53 -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 1J604K-0000j4-HE for grub-devel@gnu.org; Sat, 22 Dec 2007 03:50:52 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id C2A1D3EB23 for ; Sat, 22 Dec 2007 09:54:45 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sat, 22 Dec 2007 09:50:50 +0100 User-Agent: KMail/1.9.4 References: <1196963148.15804.44.camel@dv> <200712180357.38552.okuji@enbug.org> <20071218112952.1yxfdh3vkk08s044@webmail.spamcop.net> In-Reply-To: <20071218112952.1yxfdh3vkk08s044@webmail.spamcop.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712220950.50716.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:50:55 -0000 On Tuesday 18 December 2007 17:29, Pavel Roskin wrote: > We can alleviate it by switching to software that is already widely > used, so that the time invested into learning can be used on other > projects. Mercusial and git are good examples, as they are used in > many other projects. Monotone and darcs are not so popular; learning > them would give less benefits. I don't admit that git is popular, personally. It is famous only among Linu= x=20 fans. If we talk about popularity, CVS and Subversion outperform. Everythin= g=20 else is not popular enough to expect that one already has some experience o= r=20 can reuse experience with something else. > Actually, the great thing about git (especially when used with StGIT) > is that the changes can sit in the local tree without any problem. > CVS, on the other hand, doesn't allow any organization of the local > changes. They can be exported to a diff file and applied to the new > repository, perhaps as more than one patch. This is about git itself. I was talking about remaining changes against the= =20 CVS repository. > I don't see why we would need to migrate from git. It's good for > Linux, which is a much bigger project. It's under development, which > mean that it will improve. Much bigger does not mean that it is suitable for everything, as well as=20 supercomputer does not fit into mobile usage. Please note that Linux has been developed in a very weird way for a long ti= me.=20 =46or many, many years, Linus refused to use any kind of SCM, but he used a= =20 different kind of SCM, named Alan Cox. Since Alan did many clever things=20 autonomously, like choosing a subset of patch set, on-the-fly merging, etc.= ,=20 their usage pattern of git is still very much affected by the development=20 model in the early days. You can see a lot of other differences as well. For example, GRUB uses=20 autoconf. Linux does not. This has a good reason, as the configuration of=20 Linux is involved with many dependencies, and it is not easy to track such = a=20 graph with autoconf. But this does not mean anything like GRUB shouldn't us= e=20 autoconf. > The problem is, some patches need to be split into series. For > example, one patch prepares ground, the other makes the radical > switch, the third carries on some simplifications that become possible. > > People who learned working with patch series are annoyed by a version > control system that doesn't provide facilities for that. > > Another problem is bisecting bugs. git makes is possible in a simple, > effective and formal way, so that I don't have to look at the dates in > the changelog and guess where the next test point should be. I'm not > aware of any other version control system providing that feature. The > bisecting facility is important to assure code quality. > > Finally, things like grub4dos should not be forks, they should be > branches. This would give then a better exposure. CVS branch support > is pathetic, and the same applies to Subversion, although for > different reasons. Sure. > > You might be excited with technical innovations, but please don't forget > > that it costs to change things. Note that I don't mean that we should't > > change, but that we must be a bit more conservative with regard to SCM. > > Since we are not developing SCM itself, we should consider carefully pr= os > > and cons, before making an action. > > I see serious advantages when it comes to attracting developers, > fixing existing bugs and improving future changes. It's difficult to answer. In my case, it is the most important that I have = a=20 tool in my computer to check out a working copy, and I know how to use it=20 already. Otherwise, I tend to just give up. (In fact, I never try to=20 contribute to a project which uses darcs...) > > 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? > > I understand you are concerned about for Windows portability, not about > DOS. :) > No, git uses recursive merge by default. But I don't see why it's > important. It's interesting to know. Thank you very much. Do you have any pointer to=20 learn their algorithm for more details? > > - Free Software (definitely!) > > - Good merging algorithm (if distributed) > > - Good web interface (as good as viewvc) > > - Commit notification by email at the server side > > - Good portability (as good as CVS) > > All this is present in git. When coming to good web interface, I feel that gitweb is so difficult to=20 understand... For now, the only "acceptable" ones are viewvc and websvn for= =20 me. > > - Ability to track changes efficiently, i.e. annotation (probably > > supported by > > most SCMs) > > I don't know what it means. cvs annotate, svn blame, like that. > > - Usable interface (not like arch) > > - Good user document (like svnbook) > > git is very close, although the work is underway > > > - No conflict in a (main) repository (not like monotone) > > I think it's a policy issue. In any case, I don't see it as a problem > with git. I simply don't know if git supports this policy. > I agree, but in both cases developers will have to learn something > they won't be using elsewhere, unlike git. Again, git is not that popular. > Last time I tries svk, it was adding some useless (for other > developers) annotations to the commit messages, so I thought it would > be impolite to others to commit directly from svk to the main > repository. StGIT keeps all marks to itself. Right. Okuji