[Geany-devel] Git Switch (again)

[Colomban Wendling]

Hey,

Sorry for the response delay, but not I answer:

Le 28/04/2011 03:36, Matthew Brush a écrit :
> Summary from previous thread:
> The people in the thread who do not want to switch to Git, or those who
> don't seem to care either way, are those who have commit access to
> Subversion on SourceForge.  Most (if not all) contributors to Geany  are
> using Git (via git-svn).  The workflow for those who don't have commit
> access on the subversion repository, when contributing to Geany is
> sub-optimal (to put it politely).  SourceForge is painfully slow and the
> interface for viewing SVN source code online isn't great.

Agreed, mostly on the fact that SF is quite weirdly painful to use in
many situations.

> I think the reason GitHub/Gitorious is mentioned so much is not only
> because of the "Git" in their name, but also because it allows people
> who don't have commit access to actually be active members in the
> community, by means of having their public forked repositories, sending
> merge/pull requests, etc.

I don't know GitHub, but it looks great at first glance.
The only thing I don't necessarily like is being this much depend of an
external host, but it's probably the cost of not maintaining our own
whole set of services and servers. And anyway we already have this with SF.

The only thing I think would be awesome and really useful would be to
have the GitHub wiki on geany.org (or vice-versa). Since its seems to be
an open-source Wiki software using Git, it may be doable; and that'd be
awesome.

> Cons from the previous thread:
> - It's more social

I have some cons against social networks, but there are pros here, so...

> - Not plain enough (I guess too Web 2.0/feature-full/cluttered)

I don't personally mind if it's not intrusive.

> - Effort required to move the project

That's the big part!

> - Having to learn a new VCS for those not familiar with Git

True. Though I think Git is quite handy for the basic features
(commit/diff/log/pull/push/merges/branches/cherry-picks), probably less
with more advanced ones, but they are less used, aren't they? (though I
rebase almost everyday, but still :D)

> Pros from the thread:
> [...]
> - Moving the codebase and history is very easy, for example using the
> script from the thread or GitHub offers you to import a SVN repository
> through the web interface when creating a new repository.

That's a great point for GitHub

> - Easier to contribute to the project for those without write access
> - Faster hosting and better interface.

Seems like I agree.

> - Harder to have patches slip through the crack.
> - Not having to maintain/create patches as much/at all.

That's not necessarily true, but yes, patches at least have a proper
managing system.

> - No need to maintain changelog and authors files

That's not true. Our ChangeLog don't contain each and every commit, nor
necessarily the whole commit message.

Although I don't personally second such ChangeLog (mostly because we
have to maintain it and it's the biggest source of conflicts), I
understand the point of Nick and Enrico to keep it, and won't start
discussion on this again.

> - Proper attribution, blame and history for contributors and not having
> to put "Thanks" in all the commit messages.

That's a good point, too.

> Not sure if I missed any, or misconstrued them.
> 
> Here's some features of better project hosting sites.  I'm listing
> things from GitHub because I know it better than Gitorious and others:
> 
> - Great source code viewer, branch/file browser, history/commit viewer.
> - Ability to link to and comment on commits and even specific lines of a
> commit, for code review, etc.
> - Nice network graph viewer to get a better idea of what everyone else
> is working on, needs to be commited, etc[2].
> - Tracker for pull/merge requests so no need for contributors to
> generate/maintain patch(sets) and keep bumping ML threads so their
> patches don't go forgotten.
> - Fork queue to compare other peoples repositories' commits against your
> repository to cherry pick specific commits, with an indication of
> whether or not the commit/patch will likely cleanly apply
> - Good issue/bug tracker
> - Built-in Wiki software
> - Nice graphs to show languages, impact, commit activity, etc
> - Web hooks to notify by email/ML, IRC and other services of commits,
> etc.[4]
> - No need to create nightly tarballs separately since the server takes
> care of this automatically when users clicks the Download link.

Yeah, GitHub functionality looks great. I don't think Gitorious offers
as much functionality (e.g. no bug tracker).

The one I probably misses the most on SF is automated ticked closing
from a commit (e.g. the "closes #foo" stuff).

> Hopefully this will stir up a little discussion about actually switching
> because every time I use SourceForge I die a little inside :)  I think
> switching to one of the Git project hosting sites will really help the
> community/contributors get involved and feel like part of the team while
> still making sure the official code is controlled by a great team of
> core developers.
> 
> Obviously I'm not suggesting that the SourceForge project page is
> deleted, just switching the main development activity to elsewhere.  We
> could have a git/svn mirror over at SourceForge still, and even keep
> their bug/feature tracker, though I can't see why, since it's pretty lousy.

The difficult part is moving bug tracking I guess. If we end up having 2
bug trackers it'd become quite a pain :/

> It really wouldn't be hard either, the whole "switch" be done in
> probably 10-15 minutes, maybe 1-2hrs to wait for the history to be
> imported.  There's no real reason it needs to be a big deal either, we
> could test out another project site and keep it the way it currently is
> still with not much extra effort, just someone/somescript needs to push
> to the new project page after committing to SVN.  Basically all it would
> take beyond that is for one of the founders/core members to take some
> time to setup an account and push the code.

Before moving all main commiters should agree (e.g. Nick and Enrico),
but I think the creating par would not be the real problem. As discussed
further later in thread the problem is more setting up correct hooks to
keep all repos up to date.


As a conclusion, I completely second the Git switch, and mostly the
GitHub choice. I we all agree on this, we could try this "soon" (don't
trust this word).


Cheers,
Colomban