Re: Switching to git?

[Pavel Roskin]

Hello!

Quoting "Yoshinori K. Okuji" <address@hidden>:

> I bet that you under-estimate the pain of migrating to another SCM. I have
> experienced such migrations twice, and they were always a pain, something
> that nobody wants to repeat.

I went through some migrations (CVS to Subversion and CVS to git), and  
it's not a trivial task, but it's not a big deal for other developers  
who are not doing the migration.

> Some reasons:
>
> - The repository will be temporarily down (negligible in a long term).

Yes, negligible.

> - All developers are forced to install new software and learn it (always a
> pain).

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.

> - All local (pending) changes in working copies become very hard to merge
> (extremely painful).

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.

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

That's true, but only to a degree.  Any serious contender would have  
to support migration from git.  Mercurial had it from the first months  
if not days of development.

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.

Speaking of CVS, since it doesn't record the changesets, migrating  
from it to anything will require some guesswork.

> Since Robert was in a hurry so much, I had to stop it immediately with very
> terse words. I am sorry about that, but please do not make a haste. I have
> discussed (and objected to) possibilities to move to another SCM in the IRC,
> the mailing list, etc., but it seems that people forget my words at every
> time. It's sad to me, as I must repeat the same thing again and again.

I didn't know that.

> First of all, this is not a hurry at all. CVS is far from nice, but it has
> worked well for GRUB for the past 10 years, and we haven't had any critical
> problem with it. This is because GRUB is a very simple project from the
> viewpoint of source code management.

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.

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

git works with Cygwin, and it's not an unrealistic requirement.   
Looking at the amount of recent changes in git for things like newline  
conversion, I'm sure that they come from the developers actually  
working on Windows.  An active development community assures code  
quality and minimal bit rot.

> Besides the portability, I don't like the merging algorithm. If my knowledge
> is not completely outdated yet, git still uses 3-way merging, right? I don't
> describe the math here, as it is (a little) documented in the revctrl wiki:
>
> http://revctrl.org/CategoryMergeAlgorithm
>
> As long as git uses this naive algorithm, I am not willing to use it.

No, git uses recursive merge by default.  But I don't see why it's important.

> CVS's merging algorithm is also very simple and stupid, but it is not a big
> problem, because CVS is centralized. When getting distributed, things get far
> more complicated and critical, since there are so many corner cases where one
> cannot see in a centralized SCM.

I'm afraid I don't understand this argument.  Linux trees are merged  
all the time, and nothing particularly bad happens.  GRUB should heve  
less corener cases, not more.

> These are the requirements for a new SCM in the context of GRUB from my point
> of view:
>
> - 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.

> - Ability to track changes efficiently, i.e. annotation (probably   
> supported by
> most SCMs)

I don't know what it means.

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

> Other features are not so important, since GRUB is small.
>
> Here are some examples:
>
> - Subversion (+ svk) is good enough, if we only sometimes want to work
> offline.
>
> - Bazaar looks good, if we believe that their claim is all correct.

I agree, but in both cases developers will have to learn something  
they won't be using elsewhere, unlike git.

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.

--
Regards,
Pavel Roskin