[Kde-scm-interest] SVN closed for commits and Basic Git Groundrules
mitchell at kde.org
Tue Jul 21 13:42:27 CEST 2009
Thomas Zander wrote:
> On Tuesday 21 July 2009 13:24:18 Riccardo Iaconelli wrote:
>> Hmm... I'm a bit scared of using this approach, where you don't share the
>> work directly in the mainline repo, but instead work on your own clones. I
>> mean, while being very git-ish, aren't we losing here the social model that
>> we all love so much about KDE, and that everyone fears to loose when
>> switching away from SVN?
> This is a misconception; where the doc mentions private clone its entirely
> correct terminology but confusing.
> Let me explain with an example workflow.
> * I clone amarok on gitorious.
> * I download from my own clone
> * I start writing my new feature and push it to my own clone on gitorious
> Then I talk on IRC to get feedback for this and point others to this public
> gitorius project.
> * Bart downloads my clone and starts hacking on it.
> * I grant him write rights in my 'private' clone and he pushes to it.
> After a couple of weeks and maybe more committers on this little project we
> merge it into mainline via a normal local git command and I personally can
> push it to mainline in the master branch.
Also, the part of the thread that ended up here (kde-scm-interest)
wasn't complete. Those three guidelines I put down really mix
perspectives of normal KDE developer and occasional contributor, mainly
because of me having only been the latter on Gitorious before and being
used to that workflow :-)
Although in the main repo you should indeed never push up your branches
(so if you do need to make a branch, push it up to your own clone -- or
you could just keep it local if you don't want the online backup or need
to share it), for most work branches won't be needed. The kinds of
changes that people normally make can just be made directly into master
and pushed to the mainline repo.
The #2 you saw (and #3 about one branch per bugfix/feature) is more
applicable to a random one-off patch contributor who won't be added to
the kde-developers group. They should clone the repo, create a branch
per bugfix/feature, and then send a merge request. But note that this
doesn't break community -- it's essentially the same model as before,
where someone randomly pops up with a patch, except in this case it will
be a merge request that people can review and comment on directly on
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090721/520aec63/attachment.sig
More information about the Kde-scm-interest