On Thu, 24 Jan 2019 at 20:26, Simon Hausmann <simon.hausm...@qt.io> wrote: > > > I would see the biggest long term impact with the massive amount of cherry > picks from dev to qt6 over a long period of time. > > Git rerere works locally, so it doesn’t help in this setup I think.
Completely seriously, without any preference to either branching approach: aren't we going to be in some sort of trouble with the qt6 branch anyway, no matter what we do? Following on a bit: Pardon me if I missed some important part of the motivation of all of this, but I *CAN'T* see how this should, could, or needs to be an approach that helps with the qt6 branch merge/cherry-pick/rebase. I don't think that's going to be a pleasant operation whatever we do. I would like a "push to trunk, backport to release-branches" approach going forward. As in, once we have the usual umpteen X.y branches, it's a simple approach. But I don't see how going from merge-forward (except also merge-backward sometimes) to cherry-pick-backward (except also cherry-pick forward, or kinda sideways to qt6, and maybe sometimes merge in some direction) is going to help us with qt6. These matters seem orthogonal. Qt6 and dev are going to diverge. Drastically, eventually. I don't know how to solve that. A new branching policy is not going to help with that. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
