Stipe Tolj <st 'at' tolj.org> writes: >> Does that mean Alex has some git experience and could positively >> examine a request to migrating to git? Kannel still uses CVS, and >> it would probably make developers and contributors life easier to >> use a more powerful VCS. > > yep, Alex uses git for his own repository management. We should switch > to svn (subversion) instead for the first instance, in order to let > others follow the contribution commits more easily. Subversion is > still more "convenient" then git from old cvs users.
Don't overestimate the complexity of git; AFAIK, it was really complicated when Linus wrote it, but it was 3 years ago. Since then, a lot of auxiliary utilities making git usable for mortals were integrated into main git; and then, a lot of free software projects have moved from cvs, svn or even mercurial to git (the kernel, e2fs, alsa and probably a lot of kernel-related projects, yet also xorg, wine, cairo, ruby on rails..) which is quite meaningful to me. As for the complexity, the easiest way of posting patches is really as simple as: # git clone # ... hack, hack, hack ... # git diff > /tmp/foo.patch > Alex, is there an easy way to have a local git reposiroty that is > "exported" to a centralized svn repo? AFAIK, if you decide for svn - boo! don't! :) - there are svn-git tools which allow to use a local git repo, commit in it, and then "export" the commit to the master svn repo. (answering your other mail here as well) > didn't realize this was your own HOWTO explaining the basic steps. So > I could ask you too :) Eh, I'm really not an expert in git :) I'm rather a beginner to intermediate user, who has been quite convinced by it. > First of all: is git available on the most Linux flavor distros; the > major ones mainly, so Debian, Fedora, SuSE, Ubuntu et al? Yes, of course - don't forget that the kernel and many other projects use git now. Either by the package name "git", or "git-core", it's available everywhere. http://packages.debian.org/search?keywords=git-core https://admin.fedoraproject.org/pkgdb/packages/name/git http://www.gentoo-portage.com/dev-util/git http://download.opensuse.org/distribution/10.3/repo/oss/suse/i586/git-1.5.2.4-23.i586.rpm - sorry didn't find better for suse, is there? - http://en.opensuse.org/Package_List is a joke :) The Fedora project even hosts quite some git repos, showing off what their views on git are: http://git.fedoraproject.org/git/ > Users tend to be lazy. svn is available at all flavors. I'm not sure But contributors also tend to be lazy, and being able to contribute more effectively is a big plus :) A single example is that browsing a git repo on the web is much more powerful than using cvsweb or equivalents, because it shows commits globally and time-ordered rather than by file, which is more meaningful. Also, branching is powerful with git; it would help branch desires of contributors becoming reality more easily. Lastly, if you want to cherry pick some bugfixes and include them into stable kannel releases, you will also benefit from branches (I do use branches in CVS, I know it's possible, but it's painful). > how compatible the tagging and branching system of git is with svn. If Depends on what you mean by "compatible". Git can import cvs and svn repositories including tags and branches, AFAIK. > it is, I'd prefer a centalized svn repos, with a de-centralized git > infrastructure on the developers end. How about that? A lot of people do not use git as Linus does - e.g., it is possible to have a centralized git repo where everyone pulls from, and only a selected group of users can write to; that's actually how I use git for my projects (the "everyone will publish their modified repos" is a marketing argument, it's not practical for projects as long as no forking is desired). Then, what git allows for contributors is easily commit on their side, management of their changes, and then a unique patch posting; it makes contributors life easier because they can commit locally (so they can split their work in logical parts easily), even undo or amend commits before sending them; and then, it makes your life easier because they can submit their patches with "git-format-patch" which includes all modifications in a single file, and embeds their name and email, so that when you will commit upstream, the "author" name is kept (the contributor) and the "commiter" name also (you). Here's an example of such a commit on one of my projects: http://frozen-bubble.org/cgi-bin/gitweb.cgi?p=frozen-bubble;a=commit;h=3ca6c2413a62f68c6f48a854b52018fda8c7dd42 There's another nice benefit I already experience with git, even in the "one commiter" or even "one developer" architecture: when you're working on a non trivial feature, and suddenly you realize you want to commit something else on the already modified file (either for a urgent fix, for some cleanup you've decided when working on that file, or because you realize there's some sort of "utility" improvement to be done on that file before the actual feature), then git helps a lot, whereas the operation with CVS is manual thus painful; either you can interactively select a few hunks from the diff with "git-add -i" or "git-gui", leaving the rest for the future; or you can also use "git-stash", which just saves all the changes somewhere, moving back your working copy to the latest commit; then later, git can recover the changes automatically. Again, if you rather go with svn - boo! don't! - then nothing is needed on kannel side. Using git-svn on developers/contributors side is transparent to kannel. Now, what I'd advice, before booing git, would be that you create yourself a git repo from the kannel cvs repo (it's very easy, check my doc), and work a couple of days on it, and see for yourself. In my opinion, it's really not that complicated, and improves a lot on other systems. -- Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36
