Thread overview | |||||
---|---|---|---|---|---|
|
December 10, 2016 Please don't force-push to shared branches | ||||
---|---|---|---|---|
| ||||
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 |
December 11, 2016 Re: Please don't force-push to shared branches | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
December 11, 2016 Re: Please don't force-push to shared branches | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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. |
Copyright © 1999-2021 by the D Language Foundation