Git repositories created and how to work with them

[Milian Wolff]

Andreas Pakulat, 04.05.2010:
> Hi,
> 
> I've pushed all 5 repositories to gitorious.org/kdevelop (and the
> project page also works now): kdevplatform, kdevelop, quanta, php,
> php-docs. They're open for comitting, hence I'd like to talk a bit about
> our workflow with that. (this is not set in stone of course)
> 
> I've created a 4.0 branch already from master, thats our stable branch
> and should get all bugfix commits on it. We'll than have to make sure
> that its merged once a week (or more often for important fixes) into
> master so that master also gets the bugfixes. I don't want to be
> responsible alone for that, so if anybody notices no merge on sunday
> evening if there's been commits to 4.0 branch in the week, please just
> do the merge.
> 
> The master branch is open for any kind of commits, but only
> single-commit-change should be pushed to it directly. Everything else
> should be done in a local branch and the branch then merged into master.
> I'm thinking it makes sense to use --no-ff when doing the merge so that
> even if a fast-forward is possible we'll get a merge-commit.
> 
> For the commits themselves its important to make them self-contained,
> that is after each commit, even in a series of related commits, the code
> should be buildable. The simple reason for that is git bisect, it makes
> finding regressions really easy, but it depends on a buildable codebase
> after each commit.

Hi there.

Please bear with me on this one: I'm a total noob when it comes to the more 
advanced features of git.

But: Why can't we simply continue as before, just profiting from git where 
possible?

I mean: work solely on master like we did in SVN. Backport fixes where 
possible and necessary, like we do in KDE SVN. Just as soon as we work on 
something bigger that might break something (e.g. SmartRange -> MovingRange, 
Project*Item rework) or some new plugin / feature, work in a branch and merge 
as soon as possible.

I personally see the advantage that we are already used to that workflow and 
I'm quite satisfied with it. SVN just had to go away for the places where one 
did anything bigger that might render things unusable. But we should really 
keep things as combined as possible to make sure the codebase stays stable.

This would also fit the bisect thingy since we either fix something in a 
single commit or we merge something halfway working that at least compiles.

Or is this what you actually proposed?
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100504/6db4d341/attachment.sig>