[cmake-developers] How to develop "bigger" features ? git/gitorious etc.

Alexander Neundorf neundorf at kde.org
Fri Apr 9 14:09:04 EDT 2010

On Friday 09 April 2010, Brad King wrote:
> Alexander Neundorf wrote:
> > now that CMake is using git there are multiple ways how things can be
> > done.
> Currently we're using a cvs-like, merge-less, rebase-only workflow.
> We've discussed moving to the approach described by "git help workflows"
> but have not done it yet.  We're planning to do it soon though.
> > E.g. I have almost working support for the IAR compilers here locally,
> > not committed yet.
> > How should I proceed with this ?
> This is our first non-trivial change since the move to Git.
> Perhaps this can be the guinea pig change for the new workflow.

Well, I'm not sure it's really non-trivial, it just takes some time/commits to 
get to a working state.

> > Should I just commit/push it all at once to the git master ?
> >
> > Or, should I do the development on a clone e.g. on gitorious and then
> > request a merge ?
> Please construct a series of small, logically distinct commits
> to give each change its own meaningful commit message.  Each
> commit should still be a working CMake that is a step closer
> to the final result.  Then publish it on gitorious and we'll
> take a look.

Ok, I'll try to do this.
But, well, if I do this on a gitorious clone, I would want to commit each fix 
to my clone/branch when I have it. Since I do this only via feedback in the 
bugtracker (I don't have the IAR compiler here), I would want to push it into 
my clone, so the tester can get it from there directly.
This may give some not so "straight" commits.

If I then request a merge, you will see all these commits.

Should I then in some way create new commits in a different branch which look 
nice ?


More information about the cmake-developers mailing list