[Development] Proposal: New branch model

[Frederik Gladhorn]

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