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 ? Alex _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
