All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Switching to git?
Date: Sat, 22 Dec 2007 09:28:28 +0100	[thread overview]
Message-ID: <200712220928.28355.okuji@enbug.org> (raw)
In-Reply-To: <8763yww6mc.fsf@lab.ossystems.com.br>

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

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. http://git.or.cz/gitwiki/WindowsInstall

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.

Okuji



  parent reply	other threads:[~2007-12-22  8:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-06 17:45 Switching to git? Pavel Roskin
2007-12-06 18:04 ` Otavio Salvador
2007-12-07  1:42   ` willem
2007-12-07 11:43     ` Otavio Salvador
2007-12-08  5:39       ` willem
2007-12-08  0:06     ` Vesa Jääskeläinen
2007-12-08  1:16       ` Otavio Salvador
2007-12-08  2:54         ` Pavel Roskin
2007-12-12 14:30 ` Robert Millan
2007-12-12 15:03   ` Otavio Salvador
2007-12-12 16:21     ` Amin Azez
2007-12-12 15:36   ` Pavel Roskin
2007-12-12 16:01     ` Robert Millan
2007-12-15 10:54 ` Robert Millan
2007-12-16  4:32   ` Otavio Salvador
2007-12-16 11:03     ` Robert Millan
2007-12-16 17:21       ` Pavel Roskin
2007-12-17  7:02   ` Yoshinori K. Okuji
2007-12-17 11:11     ` Markus Elfring
2007-12-17 23:53       ` willem
2007-12-17 11:40     ` Tomáš Ebenlendr
2007-12-17 12:20       ` Markus Elfring
2007-12-17 11:58     ` Otavio Salvador
2007-12-18  0:10       ` willem
2007-12-18  1:20         ` Pavel Roskin
2007-12-18  2:04           ` Otavio Salvador
2007-12-18  2:57           ` Yoshinori K. Okuji
2007-12-18 12:05             ` Otavio Salvador
2007-12-18 18:30               ` Vesa Jääskeläinen
2007-12-18 21:32                 ` Pavel Roskin
2007-12-21 17:54                   ` Vesa Jääskeläinen
2007-12-19  0:11                 ` Gregg C Levine
2007-12-22  8:28               ` Yoshinori K. Okuji [this message]
2007-12-22 11:16                 ` Robert Millan
2007-12-23  4:58                   ` Pavel Roskin
2008-01-04 17:06                 ` Jeroen Dekkers
2008-01-04 17:39                   ` Otavio Salvador
2007-12-18 16:29             ` Pavel Roskin
2007-12-22  8:50               ` Yoshinori K. Okuji
2007-12-22 11:20                 ` Robert Millan
2007-12-22 12:28                   ` Yoshinori K. Okuji

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200712220928.28355.okuji@enbug.org \
    --to=okuji@enbug.org \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.