question/guidence regarding merge to master

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

question/guidence regarding merge to master

Boost - Dev mailing list
I'm looking to merge my develop branch into the master so that they will
be in sync.  I'm thinking that this the changed in develop should be
squashed so that the master branch doesn't included all the the
intermediate changes made during the develop phase.  Is there any boost
rule/practice/guidence regarding this?.  Ideally, I'd like to see the
master have only one set of consolidated changes for each release.  But
I'm not the person who decides these things or does the work.  Any
insight by other parties would be appreciated.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
Hi Robert,

On 2019-01-10 9:20 p.m., Robert Ramey via Boost wrote:
> I'm looking to merge my develop branch into the master so that they
> will be in sync.  I'm thinking that this the changed in develop should
> be squashed so that the master branch doesn't included all the the
> intermediate changes made during the develop phase.  Is there any
> boost rule/practice/guidence regarding this?.  Ideally, I'd like to
> see the master have only one set of consolidated changes for each
> release.  But I'm not the person who decides these things or does the
> work.  Any insight by other parties would be appreciated.

I don't think there is (and should be) a Boost-global rule on how to
handle this, though some guidelines might be useful.

(There tend to be different camps of people  with different preferences,
such as the ones preferring clean branches who tend to use `git rebase`
a lot versus those who frown upon `rebase` (and history rewrites) as
they insist on clear audit trails, especially if code reviews are
involved. So rather than opening the door for yet another area of
endless debate, I'd simply recognize such styles, and document pros and
cons.

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.

--

Stefan
 

       ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Robert Ramey wrote:
> I'm looking to merge my develop branch into the master so that they will
> be in sync.  I'm thinking that this the changed in develop should be
> squashed so that the master branch doesn't included all the the
> intermediate changes made during the develop phase.  Is there any boost
> rule/practice/guidence regarding this?.  Ideally, I'd like to see the
> master have only one set of consolidated changes for each release.  But
> I'm not the person who decides these things or does the work.  Any insight
> by other parties would be appreciated.

My guideline is:

- work that has passed local tests goes into a feature branch
- feature branches that have passed CI go into develop
- develop that has not broken anything goes into master

That is, develop is not a place for experimentation (or, ironically stated,
develop is not for development). The squashing, if needed, happens on the
merge from the experimental feature branch into develop, not on the merge
from develop to master. Ideally, the merge from develop to master is
fast-forward and the two contain the same commits, with master just trailing
behind.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
On 1/10/19 6:58 PM, Peter Dimov via Boost wrote:

> Robert Ramey wrote:
>> I'm looking to merge my develop branch into the master so that they
>> will be in sync.  I'm thinking that this the changed in develop should
>> be squashed so that the master branch doesn't included all the the
>> intermediate changes made during the develop phase.  Is there any
>> boost rule/practice/guidence regarding this?.  Ideally, I'd like to
>> see the master have only one set of consolidated changes for each
>> release.  But I'm not the person who decides these things or does the
>> work.  Any insight by other parties would be appreciated.
>
> My guideline is:
>
> - work that has passed local tests goes into a feature branch
> - feature branches that have passed CI go into develop
> - develop that has not broken anything goes into master
>
> That is, develop is not a place for experimentation (or, ironically
> stated, develop is not for development). The squashing, if needed,
> happens on the merge from the experimental feature branch into develop,
> not on the merge from develop to master. Ideally, the merge from develop
> to master is fast-forward and the two contain the same commits, with
> master just trailing behind.

Hmm - but then when the CI fails on develop and a few more tweaks are
necessary basically to deal with compiler/ci vagaries, this cruft then
ends up on the master history.

Also, then shouldn't master just be just a tag into the the last passing
develop branch?

I do think it would be useful for someone to "codify" these practices
because a lot of don't know (and don't really want to know) and don't
really care which practices to follow and would be happy to follow
whatever someone who spends time with this stuff has concluded would be
the best way.

just my 2 cents.

Robert Ramey

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 11 Jan 2019 at 03:59, Peter Dimov via Boost
<[hidden email]> wrote:

> Robert Ramey wrote:
> > I'm looking to merge my develop branch into the master so that they will
> > be in sync.  I'm thinking that this the changed in develop should be
> > squashed so that the master branch doesn't included all the the
> > intermediate changes made during the develop phase.  Is there any boost
> > rule/practice/guidence regarding this?.  Ideally, I'd like to see the
> > master have only one set of consolidated changes for each release.  But
> > I'm not the person who decides these things or does the work.  Any insight
> > by other parties would be appreciated.
>
> My guideline is:
>
> - work that has passed local tests goes into a feature branch
> - feature branches that have passed CI go into develop
> - develop that has not broken anything goes into master
>
> That is, develop is not a place for experimentation (or, ironically stated,
> develop is not for development). The squashing, if needed, happens on the
> merge from the experimental feature branch into develop, not on the merge
> from develop to master.

I second and follow the same as Peter's while working on Boost.GIL.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 11 Jan 2019 at 06:05, Robert Ramey via Boost
<[hidden email]> wrote:

> On 1/10/19 6:58 PM, Peter Dimov via Boost wrote:
> > Robert Ramey wrote:
> >> I'm looking to merge my develop branch into the master so that they
> >> will be in sync.  I'm thinking that this the changed in develop should
> >> be squashed so that the master branch doesn't included all the the
> >> intermediate changes made during the develop phase.  Is there any
> >> boost rule/practice/guidence regarding this?.  Ideally, I'd like to
> >> see the master have only one set of consolidated changes for each
> >> release.  But I'm not the person who decides these things or does the
> >> work.  Any insight by other parties would be appreciated.
> >
> > My guideline is:
> >
> > - work that has passed local tests goes into a feature branch
> > - feature branches that have passed CI go into develop
> > - develop that has not broken anything goes into master
> >
> > That is, develop is not a place for experimentation (or, ironically
> > stated, develop is not for development). The squashing, if needed,
> > happens on the merge from the experimental feature branch into develop,
> > not on the merge from develop to master. Ideally, the merge from develop
> > to master is fast-forward and the two contain the same commits, with
> > master just trailing behind.
>
> Hmm - but then when the CI fails on develop and a few more tweaks are
> necessary basically to deal with compiler/ci vagaries, this cruft then
> ends up on the master history.

There is possibility that infrastructure stuff is different in master
vs develop,
or minor maintenance of build scripts and tweaks go into develop directly.
Such exception to Peter's is not uncommon.
It's also possible tweaks go into master only
But, since Boost does GitFlow, master is never merged into develop,
so it should not be a problem for merges in the reverse direction.

> Also, then shouldn't master just be just a tag into the the last passing
> develop branch?

Are  you suggesting departure from GitFlow, or has it already happened?

> I do think it would be useful for someone to "codify" these practices
> because a lot of don't know (and don't really want to know) and don't
> really care which practices to follow and would be happy to follow
> whatever someone who spends time with this stuff has concluded would be
> the best way.

I'd be happy to learn myself too.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1/11/19 5:58 AM, Peter Dimov via Boost wrote:
>
> My guideline is:
>
> - work that has passed local tests goes into a feature branch
> - feature branches that have passed CI go into develop
> - develop that has not broken anything goes into master
>
> That is, develop is not a place for experimentation (or, ironically
> stated, develop is not for development).

What's the purpose of develop then?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
On Fri, 11 Jan 2019 at 11:26, Andrey Semashev via Boost
<[hidden email]> wrote:

> On 1/11/19 5:58 AM, Peter Dimov via Boost wrote:
> >
> > My guideline is:
> >
> > - work that has passed local tests goes into a feature branch
> > - feature branches that have passed CI go into develop
> > - develop that has not broken anything goes into master
> >
> > That is, develop is not a place for experimentation (or, ironically
> > stated, develop is not for development).
>
> What's the purpose of develop then?

Production staging?
A safety net master is always shippable?

But I've also wondered about it, hence my question in response to Robert's post.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list

>> What's the purpose of develop then?
> Production staging?
> A safety net master is always shippable?
>
> But I've also wondered about it, hence my question in response to Robert's post.

Exactly that. You usually have CI on 3 levels (possibly with increasing
complexity on e.g. compilers tested):

1. PRs
2. develop
3. master

Why is the 2nd stage required? Assume you have 2 MRs. The first
introduces a new file using some existing functionality. The 2nd
changes/removes/renames that existing functionality and all references.
Both MRs pass CI and are merged. But now your develop is broken as the
update from the 2nd was not applied to the feature in the 1st. Another
commit (possibly directly to develop) fixes this after which CI passes.
Now you can put this into master.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Jan 10, 2019 at 9:20 PM Robert Ramey via Boost <
[hidden email]> wrote:

> I'm looking to merge my develop branch into the master so that they will
> be in sync.  I'm thinking that this the changed in develop should be
> squashed so that the master branch doesn't included all the the
> intermediate changes made during the develop phase.  Is there any boost
> rule/practice/guidence regarding this?.  Ideally, I'd like to see the
> master have only one set of consolidated changes for each release.  But
> I'm not the person who decides these things or does the work.  Any
> insight by other parties would be appreciated.
>
> Robert Ramey
>
>
Any merge from master into develop should be empty (i.e. nothing to do).
This ensures you didn't miss anything in the past through a bad procedure.
(for example someone checking into master directly, which I've seen)

Any merge from develop into master should always be a fast-forward.
If you squash commits when going from develop to master, you cannot
prove that develop is missing anything from master because you cannot
merge master into develop.

I had to do this and fix up the missing/conflicts on all the CMT
repositories.
I'd also recommend if you have more branches lying around than develop
and master that you consider removing them unless they are for active
team development of a feature.  Otherwise you should be using a fork and
using your own travis and appveyor accounts to prep your changes so that
you do not consume Boost CI resources.

My recommendation is that your commits to develop are considered project
history and they do not get rewritten by rebase or squash into master, and
certainly never by a force push.

Pull requests run the same CI as a push does, so you should be able to get
CI stable on your PR before you rebase your PR into develop.  Then you
can always merge (fast-forward) develop into master.

I don't see any benefit in consolidating all the changes in master to one
commit.  You can accumulate all the changes using git by comparing the
tags between releases.  Further nobody who consumes boost from a release
sees any of this stuff anyway.

If you want to fix your branches, do this:

1. git clone your-repo
2. git checkout -t origin/develop
3. git merge master

If you have any commits in master not in develop, this will pick them up.

4. git push
5. git checkout master
6. git merge develop

This merge should be a fast-forward because of what you did in 3.

What you proposed by squashing commits into master would cause
us to have to force push a new consolidated commit into master during
the release cycle, which would rewrite history, which is bad for everyone.

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1/11/19 5:20 AM, Robert Ramey via Boost wrote:
> I'm looking to merge my develop branch into the master so that they will
> be in sync.  I'm thinking that this the changed in develop should be
> squashed so that the master branch doesn't included all the the
> intermediate changes made during the develop phase.  Is there any boost
> rule/practice/guidence regarding this?.  Ideally, I'd like to see the
> master have only one set of consolidated changes for each release.  But
> I'm not the person who decides these things or does the work.  Any
> insight by other parties would be appreciated.

I think, squashing commits when merging to master is a terrible idea
because it makes tracking differences between develop and master
difficult and tracking history of changes by master log virtually
impossible. I don't see why would anyone would want to do that.

There is also a possible issue with commit authorship, which is
presumably lost when you squash commits. Depending on how you deal with
commit messages, these might be lost as well.

Of course, the decision is yours, so you can do that if you want to. But
I hope you're not meaning to force-push to develop the squashed commits
because that would affect everyone using develop of your library. In
particular, it would break git pull. Also, it breaks superproject, which
now references non-existant commits from your git repo. IMO,
force-pushing to develop and master should be locked for all libraries.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
On Fri, 11 Jan 2019 at 14:30, Andrey Semashev via Boost
<[hidden email]> wrote:
> IMO, force-pushing to develop and master should be locked for all libraries.

+1

If there is a team of maintainers, granting right to merge into master
just one of them is also worth to consider.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1/11/19 5:29 AM, Andrey Semashev via Boost wrote:
> I think, squashing commits when merging to master is a terrible idea
> because it makes tracking differences between develop and master
> difficult

When I look at the history of develop and master I expect to see:

on develop - all the history which led me to each release.

on master - the history of the releases - and nothing else.

As it is now - I see in the master the detailed history with a lot small
changes - same as the develop.  It makes me reluctant to check small
changes to develop knowing that all this transient unintrestesing and
confusing history will be forever with us.

I guess it comes down to this.  If the master is just a copy of develop
then what's the point of it?  It's just one more thing to get out sync.
Having a master only seems to make sense if it's a different thing - ie
a history of releases.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 11.01.19 um 03:40 schrieb Stefan Seefeld via Boost:

> Hi Robert,
>
> On 2019-01-10 9:20 p.m., Robert Ramey via Boost wrote:
>> I'm looking to merge my develop branch into the master so that they
>> will be in sync.  I'm thinking that this the changed in develop should
>> be squashed so that the master branch doesn't included all the the
>> intermediate changes made during the develop phase.  Is there any
>> boost rule/practice/guidence regarding this?.  Ideally, I'd like to
>> see the master have only one set of consolidated changes for each
>> release.  But I'm not the person who decides these things or does the
>> work.  Any insight by other parties would be appreciated.
>
> I don't think there is (and should be) a Boost-global rule on how to
> handle this, though some guidelines might be useful.
>
> (There tend to be different camps of people  with different preferences,
> such as the ones preferring clean branches who tend to use `git rebase`
> a lot versus those who frown upon `rebase` (and history rewrites) as
> they insist on clear audit trails, especially if code reviews are
> involved. So rather than opening the door for yet another area of
> endless debate, I'd simply recognize such styles, and document pros and
> cons.
>
> 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.

HTH,
Deniz

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1/11/19 5:30 PM, Robert Ramey via Boost wrote:

> On 1/11/19 5:29 AM, Andrey Semashev via Boost wrote:
>> I think, squashing commits when merging to master is a terrible idea
>> because it makes tracking differences between develop and master
>> difficult
>
> When I look at the history of develop and master I expect to see:
>
> on develop - all the history which led me to each release.
>
> on master - the history of the releases - and nothing else.
>
> As it is now - I see in the master the detailed history with a lot small
> changes - same as the develop.  It makes me reluctant to check small
> changes to develop knowing that all this transient unintrestesing and
> confusing history will be forever with us.

What do you mean by the history of releases? You can already see the
list of releases by git tag. If you want to see the changes between
releases then the git log or git diff between the two tags gives you
that - in addition to keeping the particular commits that are referenced
by PRs, issues and what not with their respective authors and comments.
Having git log show only one commit per release, saying something like
"Boost X.Y release" is not helpful, IMO.

To illustrate, just the other day I had to track down a change in
Boost.Filesystem so that I could tell a user when a bug appeared in the
code and when it was fixed. I was able to do that, both in terms of
Boost realeases and commits with their respective commit messages and
dates, because I had a fine grained history with tags. I was able to
track down the particular PRs, if I had to. I think, this is an
important feature of the detailed git history.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
On 1/11/19 7:16 AM, Andrey Semashev via Boost wrote:
\
> To illustrate, just the other day I had to track down a change in
> Boost.Filesystem so that I could tell a user when a bug appeared in the
> code and when it was fixed. I was able to do that, both in terms of
> Boost realeases and commits with their respective commit messages and
> dates, because I had a fine grained history with tags. I was able to
> track down the particular PRs, if I had to. I think, this is an
> important feature of the detailed git history.

Right - but couldn't you have done that with the develop History?

Robert Ramey
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
On 1/11/19 6:21 PM, Robert Ramey via Boost wrote:

> On 1/11/19 7:16 AM, Andrey Semashev via Boost wrote:
> \
>> To illustrate, just the other day I had to track down a change in
>> Boost.Filesystem so that I could tell a user when a bug appeared in
>> the code and when it was fixed. I was able to do that, both in terms
>> of Boost realeases and commits with their respective commit messages
>> and dates, because I had a fine grained history with tags. I was able
>> to track down the particular PRs, if I had to. I think, this is an
>> important feature of the detailed git history.
>
> Right - but couldn't you have done that with the develop History?

No, because release tags are applied to the commits in master that are
used to ship a Boost release.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost
<[hidden email]> 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

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Mateusz Loskot via Boost
> Sent: 11 January 2019 15:27
> To: [hidden email]
> Cc: Mateusz Loskot
> Subject: Re: [boost] question/guidence regarding merge to master
>
> On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost
> <[hidden email]> 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.

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






_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: question/guidence regarding merge to master

Boost - Dev mailing list
On Fri, 11 Jan 2019 at 17:11, Paul A. Bristow via Boost
<[hidden email]> wrote:

> > -----Original Message-----
> > From: Boost [mailto:[hidden email]] On Behalf Of Mateusz Loskot via Boost
> > Sent: 11 January 2019 15:27
> > To: [hidden email]
> > Cc: Mateusz Loskot
> > Subject: Re: [boost] question/guidence regarding merge to master
> >
> > On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost
> > <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12