[Geany-devel] Git switch
techet at xxxxx
Wed Jun 16 11:21:49 UTC 2010
On Tue, Jun 15, 2010 at 17:42, Nick Treleaven
<nick.treleaven at btinternet.com> wrote:
> On Sun, 13 Jun 2010 14:22:05 +0200
> Enrico Tröger <enrico.troeger at uvena.de> wrote:
>> > > > > I have a few years of daily experience both with SVN and GIT.
>> > > > > We use SVN at work and I use GIT for all my personal projects.
>> > > > > I like GIT better than SVN.
>> > > > >
>> > > > > In my humble opinion you shouldn't switch unless you are unhappy
>> > > > > with sourceforge / svn.
>> > > >
>> > > > I agree. For our current development process I don't see any big
>> > > > need to change away from SVN. It will cost a lot of effort with
>> > > > no extra profit adding.
>> > > >
>> > >
>> > > I'd like to second that. And, while I use local Git repository
>> > > for Geany, I'm completely happy with git-svn (and my separate SVN
>> > > branch, of course :).
>> > I agree. Same here.
>> Well, if Frank doesn't want to and Nick doesn't mind, we maybe can
>> indeed save us the whole trouble of discussing about switching :).
> To be honest, it would be some hassle for me to switch. I only have
> experience using Git locally, no push/pull/branches. But that
> experience was great, I like the tool.
> So I think as Lex has suggested, that we shouldn't switch right now.
> Maybe some time in the future. I don't have time ATM to
> learn Git/investigate switching.
> Also as regards sourceforge, I agree with Enrico that we want to stay
> with them for now at least.
Just for those interested, I have created a complete import of your
SVN repo to git. The result is here:
It contains all the branches and all the tags you have created (many
of the branches could be deleted I guess) and the whole history since
2005. Here's what I did (may be useful if you decide to migrate to git
in the future). Basically I followed the instructions here:
and downloaded the conversion scripts.
1. You have to create the authors file with names and email addresses
of the committers. Each line has the form:
committer = full name <email at address.com>
This was easy because most of them are already present in your git
mirror. The missing ones were:
"(no author)" was used for the initial import so I used Enrico here. I
think I found the correct name and email for "clytie", but I had no
idea for kretek and statc so I used just a fake name and email for
git svn clone --authors-file=authors.txt --prefix=svn/ --stdlayout
(wait about 90 minutes until everything gets downloaded)
3. Make proper tags and branches:
The result could probably be manually improved for some merges but I
don't know if it's worth the work.
4. Push the result:
git remote add origin git at gitorious.org:geany/complete.git
git push --all
git push --tags
Just a few more comments related to the possible switch. First, just
an observation - the people who said they don't mind are those who
have write access to SVN. I agree that for them the switch is much
less important - they can create their branches to develop and back up
the work in progress and for their own development the current
workflow is OK. The current situation is worse for external
contributors who don't submit their patches so often to have SVN
access. They either don't have their work backed up, or they have to
create their own repository e.g. at gitorious as I did. When they
finish their work, they can't just tell "please pull from here" but
have to submit their patches by email. This is harder for the
maintainers too - they have to manually apply the patches from the
email instead of just "git pull". Finally, it will be the maintainer
who makes the commit and the information about the original committer
is lost with SVN - with git you see every single commit author (this
means you have to add some "thanks to" to the commit message for SVN -
this work would be eliminated with git). Finally, you can forget about
updating ChangeLog - this can be generated automatically by git (GNOME
libraries usually have one pre-git ChangeLog and then a changelog
automatically generated from the git history during "make distcheck").
So what I want to say here is that while the core developer's
development work won't be affected by the switch much, the
collaboration with external developers will improve considerably.
On the other hand you are right - git is a bit harder to use and there
will be many "doh" moments. The learning curve is steeper that with
SVN but when you learn it (I really don't want to make an impression
I'm an expert here - git still surprises me sometimes), you'll realize
git is a very powerful and helpful tool.
There has been some discussion about changing the bug tracker at the
same time - I would make it an independent issue. My personal opinion
is that you should just stay with sourceforge - moving the whole bug
tracker somewhere else is too much manual work rewarded by too little
More information about the Devel