On fredag 25. januar 2019 21:40:07 CET Thiago Macieira wrote: > 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).
There is "git cherry" which tries to determine if something has been cherry- picked between branches. But it's clearly not the most widely known, nor one of the best tools in the git offering. I have to look up up the order of source and destination arguments every time I run it... and then I still get it wrong. And indeed, the information that a cherry-pick happened is not properly recorded (which is why git cherry-pick -x is pretty much a must). https://git-scm.com/docs/git-cherry Cheers, Frederik _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
