Re: [boost] Seems like I need write-access to merge a PR

Subject: Re: [boost] Seems like I need write-access to merge a PR
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-10-25 19:16:56

On 25.10.2017 15:03, Vinnie Falco via Boost wrote:
> On Wed, Oct 25, 2017 at 11:29 AM, Stefan Seefeld via Boost
> <boost_at_[hidden]> wrote:
>> That is no longer true (and hasn't for quite a while). Nowadays the web
>> interface allows you to select different PR merge methods, including the
>> traditional merge commit, a "squash and merge", or a "rebase and merge".
>> It sounds like what you'd prefer is the latter, to make the history linear.
> I do like the linear history where practical but that is not the only
> reason to avoid using the GitHub interface.
>
> Assembling the branch locally has an additional benefit. You can
> preview exactly how the branch will look after the merge. This is not
> possible with the GitHub interface. You also cannot sign commits with
> the GitHub interface or make adjustments. Everyone who has ever
> submitted a pull request always forgets to update CHANGELOG.md.
Why would anyone still maintain a ChangeLog ? :-)
(Seriously, I'm all for keeping logs such as "release notes", but they
are much coarser grained and targeted at different audiences. For
everything else I use commit logs.)

> Furthermore I have a policy in my repository that the tip of the
> master and develop branches that the top commit always sets an
> internal version number. Merging a pull request won't accomplish that.

Again, why not just use SHAs for that ? What additional information do
you expect such a strictly defined version number to carry ? (And again,
for anything higher level there are tags...)

Anyhow, this is likely the wrong thread to have such a discussion. But
as you describe your preferred workflow, I'm curious and would like to
understand your rationale for it.

(Incidentally, I do have such repos, too, where the "master" branch is
always considered stable, and the only commits to it are
(coarse-grained) PR merges. There it might make sense to have a
highlevel "change log" as well as version tag for each PR I create. In
fact, I have my github CI infrastructure  set up to do just that: create
a new tag for each commit to master, then run tests and generate a new
snapshot including online docs. That works perfectly fine, including
triggers via the github web interface.)

Regards,

Stefan

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