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