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