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

On 25.10.2017 15:03, Vinnie Falco via Boost wrote:

On Wed, Oct 25, 2017 at 11:29 AM, Stefan Seefeld via Boost 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...