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

On Fri, 11 Jan 2019 at 17:11, Paul A. Bristow via Boost wrote:

...

-----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.

Indeed! My point was to illustrate, perhaps unnecessarily, that there are too many Git-basd religions. People suggesting X way superior to Y way often forget those small details that make huge difference. Just to point out a few, perhaps unnecessarily again: e.g. inward vs outward direction, https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215#comment-13... or the fact that most of Git workflows discussed out there assume Web app development where `master` is always shippable and there are no long-lived release branches that need to be maintained, etc.

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?

Despite GitFlow has been receiving bad PR latel, it seems to be serving Boost super-project quite well for the reason you pointed earlier: integration of multiple individual project does require an extra area for pre-production staging. Any other, simplier workflow may fail. What is maintainer's local workflow for integrating changes into library's master or develop is not a concern of Boost maintenance. A library is a submodule after all, with separate history. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net