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

Subject: Re: [boost] question/guidence regarding merge to master
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-01-11 16:43:44

On Fri, 11 Jan 2019 at 17:11, Paul A. Bristow via Boost
<boost_at_[hidden]> wrote:
> > -----Original Message-----
> > From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Mateusz Loskot via Boost
> > Sent: 11 January 2019 15:27
> > To: boost_at_[hidden]
> > Cc: Mateusz Loskot
> > Subject: Re: [boost] question/guidence regarding merge to master
> >
> > On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost
> > <boost_at_[hidden]> 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/contributing.md#merging-pull-requests-for-
> > 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-4fa1a48c53aa
> >
> > "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-1329205
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