Merge or Cherry-Pick?

[Oswald Buddenhagen]

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.