Boost logo

Boost :

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



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

Boost list run by bdawes at, gregod at, cpdaniel at, john at