On Mon, Jan 31, 2011 at 11:27:15PM +0100, Thiago Macieira wrote: > On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote: > > something that hasn't been written down as far as I can see (if I > > overlooked it, please point me to it) is what the policy on kdelibs is > > to be now wrt. merging vs. cherry-picking of changes in branches and > > master? > > Commit to 4.6, merge 4.6 into master. > that's hard enough in qt, and there is totally no way that kde's discipline would be sufficient to make forward-merging feasible (as in "actually helpful and producing an even remotely readable history"). therefore i'm for cherry-picking, preferably with a mandated -x flag. of course that means no merge tracking whatsover, which is about as much as we used from svn when it comes to bugfix backports.
hint: cherry-picking between branches is much nicer if only master is a real clone and the other "repos" are created with git-new-workdir, as then you don't need to push between repos to cherry-pick. but beware the caveats like a shared stash stack (that's actually a feature, but may still backfire) and that you must never work on the same branch in different workdirs.