Re: [boost] question/guidence regarding merge to master

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 11 January 2019 15:27 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: Re: [boost] question/guidence regarding merge to master

On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost wrote:

...

Am 11.01.19 um 03:40 schrieb Stefan Seefeld via Boost:

...

As to guidelines, there are a few useful documents online, such as https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/cont...

contributors-with-write-access,

...

which I find quite helpful. Collecting such notes on our wiki might be useful.

I lately found this very good (and long), educational blog-entry [1] which explains when and how to use `git merge` and `git rebase`.

I highly recommend everyone using Git reads it and adopts it.

[1] https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c...

"I’ll cherry-pick every commit one by one"?

"You fools, you have no idea what you are doing!" - could have the mighty Raymond Chen call [1]

Please, let's not drift this discussion into the religious battle of merge vs rebase and alike.

We (Boost) are already heavy-weight sinners sticking to the "GitFlow considered harmful" [2]

[1] https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215 [2] https://www.endoflineblog.com/gitflow-considered-harmful

But neither of these articles mention using sub-projects, a key difference with Boost's git structure. I feel that I'd like to get 'my' branch straight before trying to cope with the effect of changes in other branches (unless that was what I really was trying to resolve). Looking at the test matrix shows far more platforms and compilers than I can test locally. So is that what develop is for? Maybe others feel the same of about 'their' branches. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830