On Friday, 25 January 2019 01:10:35 PST Simon Hausmann wrote: > I do quite like what Allan suggested: We could try the cherry-pick the other > way around. Volker, Lars, Thiago etc. surely remember the p4i script we > used to have when we were using Perforce. Imagine that with more > automation.
I vaguely remember it. But your bringing it up is *not* an argument in favour of cherry-picking. Doing backporting properly in the Perforce days was a nightmare. We did not consistently backport fixes to earlier releases, even when we had a somewhat long stable series (4.3 went through 4.3.5). Also, unlike Git, Perforce "merges" *were* a series of cherry-picks and it did know which commits had been cherry-picked and which ones hadn't. So if you told it to merge a range, it would tell you everything that was missing. More importantly, the range did not have to be contiguous, so you could cherry-pick only your own changes and let others deal with theirs. It also helped p4 had a pretty good automated conflict resolution in the command-line (today, I use kdiff3 for that, via git mergetool). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
