[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Switching to git?

From: Yoshinori K. Okuji
Subject: Re: Switching to git?
Date: Sat, 22 Dec 2007 09:50:50 +0100
User-agent: KMail/1.9.4

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 Linux 
fans. If we talk about popularity, CVS and Subversion outperform. Everything 
else is not popular enough to expect that one already has some experience or 
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 
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 
supercomputer does not fit into mobile usage.

Please note that Linux has been developed in a very weird way for a long time. 
For many, many years, Linus refused to use any kind of SCM, but he used a 
different kind of SCM, named Alan Cox. Since Alan did many clever things 
autonomously, like choosing a subset of patch set, on-the-fly merging, etc., 
their usage pattern of git is still very much affected by the development 
model in the early days.

You can see a lot of other differences as well. For example, GRUB uses 
autoconf. Linux does not. This has a good reason, as the configuration of 
Linux is involved with many dependencies, and it is not easy to track such a 
graph with autoconf. But this does not mean anything like GRUB shouldn't use 

> 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.


> > 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 pros
> > 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 
tool in my computer to check out a working copy, and I know how to use it 
already. Otherwise, I tend to just give up. (In fact, I never try to 
contribute to a project which uses darcs...)

> > Ok, now about the git. As Tomáš pointed out, the lack of portability 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 
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 
understand... For now, the only "acceptable" ones are viewvc and websvn for 

> > - 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]