• David Nadlinger via digitalmars-d-ldc (10/10) Dec 10 2016 Dear all,
• Seb (4/14) Dec 10 2016 How about enabling force-push protection on GitHub?
• kinke (10/20) Dec 11 2016 That was me obviously, and the reason is the same as for beta4 -

David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:

Dear all,

The release-1.1.0 branch was force-pushed to recently. As a hard and 
fast rule, don't do this on any branch you can reasonably expect other 
people have checked out as well. There are obviously exceptions 
(emergency fixups after committing big files, breaking the history, 
etc.), but in such cases it would still be considerate to then notify 
other people of what is going on. This is common open-source folklore 
for a reason.

Thanks.

  — David

Seb <seb wilzba.ch> writes:

On Saturday, 10 December 2016 at 17:03:51 UTC, David Nadlinger 
wrote:
 Dear all,

 The release-1.1.0 branch was force-pushed to recently. As a 
 hard and fast rule, don't do this on any branch you can 
 reasonably expect other people have checked out as well. There 
 are obviously exceptions (emergency fixups after committing big 
 files, breaking the history, etc.), but in such cases it would 
 still be considerate to then notify other people of what is 
 going on. This is common open-source folklore for a reason.

 Thanks.

  — David

How about enabling force-push protection on GitHub?

https://github.com/blog/2051-protected-branches-and-required-status-checks

kinke <noone nowhere.com> writes:

On Saturday, 10 December 2016 at 17:03:51 UTC, David Nadlinger 
wrote:
 Dear all,

 The release-1.1.0 branch was force-pushed to recently. As a 
 hard and fast rule, don't do this on any branch you can 
 reasonably expect other people have checked out as well. There 
 are obviously exceptions (emergency fixups after committing big 
 files, breaking the history, etc.), but in such cases it would 
 still be considerate to then notify other people of what is 
 going on. This is common open-source folklore for a reason.

 Thanks.

  — David

That was me obviously, and the reason is the same as for beta4 - 
keeping the history (and branch comparisons) clean by rebasing 
the 3 1.1-specific commits (reverts+backport) onto master (and 
getting rid of your 2 then redundant cherry-picks for beta5); 
there were are about 30 commits since beta5, and neither 
cherry-picking nor merging master made sense to me. I've had a 
discussion with Johan starting at 
https://github.com/ldc-developers/ldc/issues/1862#issuecomment-263003598, your
input there would have been more helpful than this forum post.