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
> > -----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 
> > > which explains when and how to use `git merge` and `git rebase`.
> > >
> > > I highly recommend everyone using Git reads it and adopts it.
> > >
> > >  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 
> > 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" 
> >  https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215
> >  https://www.endoflineblog.com/gitflow-considered-harmful
> But neither of these articles mention using sub-projects, a key difference with Boost's git structure.
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,
or the fact that most of Git workflows discussed out there assume Web
where `master` is always shippable and there are no long-lived release
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.
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk