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 Gitorious itself. --Jeff
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
