Re: Moving to git?

Guillaume Cottenceau schrieb:
> 
> 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.

now, I know... but these are for "hack-alike" people more. Our user base 
isn't usually that C-affine and tend to come from the Java corner 
mainly, so svn is a term for them more then git. That's my major 
concern: making the handling for the user side easy.

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

ok, that was a solution I would go for. Having git local repos and 
export (remote commit) to a svn master.

> Eh, I'm really not an expert in git :) I'm rather a beginner to
> intermediate user, who has been quite convinced by it.

;)

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

ok, great. Thanks for the research here. That makes a major step towards 
it.

We could postulate a master svn and a shared git repo on kannel.org I 
guess simultaneously, right? Not quite sure if it would be intelligent 
to let the user "decide" which VC to use.

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

yep, agree. While using svn via Eclipse IDE would have also a powerfull 
source/revision tracing functionality. That's what I do ;)

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

yep, that's right. While branching/merging in svn is way more easier 
then cvs. Still, svn is a re-architectured VC and has more advanced 
concepts then CVS. (mainly each commit results in a whole revision tag, 
rather then revisioning single files like CVS does).

> Depends on what you mean by "compatible". Git can import cvs and
> svn repositories including tags and branches, AFAIK.

now, not looking for pure import compatibility, more into branching and 
merge applying compatibility. Which means, can we develop within git 
locally for the developers, and "clone" each operation within the 
central svn master?

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

understand.

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

now the secret: I did work with git a some days :p ... we haven't yet 
moved to svn. Alex and I had been talking about it. Now, we have another 
option with git.

Thanks a lot for your advocation to git. I and the group appreciate it 
highly. It has spotted light on git. I guess we should see what the 
others say about it and then get a vote poll on the decision.

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------