[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:28:28 +0100
User-agent: KMail/1.9.4

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.

From a theoretical point of view, you're definitely right, but the reality 
looks reverse to me. For instance, look at the inability of developers to 
editors... Even if Emacs is far superior when writing GNU-style C code, vi 
users never try to learn how to use Emacs. When it comes to command-line 
utilities vs. graphical applications, the situation is even worse.

In my experience, (unfortunately) developers are too lazy to change tools. 
They change, only when they are forced or excited for some (geeky) reason. 
This includes myself.

> > - All local (pending) changes in working copies become very hard to merge
> > (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 POV.

It is a problem. It is catastrophic, especially when an original repository is 

BTW, I have 4 different working copies of GRUB locally. All of them have 
small, different changes not committed. Do you think I would be happy to deal 
with these changes with a "mostly-working" solution? If I don't see more 
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áš pointed out, the lack of portability 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.

I can't say if it is good or not, since I myself does not use Windows at all 
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 
importance, until they get weird merging results, and spend several days only 
to fix up wrong results. However, if you notice a merging problem, you are 
still lucky; in particular when you merge big changes, it is not easy to see 
how merging went well. Sometimes, having conflicts is much better, because 
you obtain a chance to see what your SCM thinks. When merging is done 
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 data 
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.


reply via email to

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