Closed packysauce closed 7 years ago
How does this change coverage? I'll be getting automatic coverage checking up next to make it a bit easier to track.
Otherwise I think this looks good, the commits need to be squashed and updated per the CONTRIBUTING doc style guide. Thanks!
Alright I think I finally figured out how to get the commits looking the way we want them.
The easiest way I've found is to use git reset COMMITBEFORENEWONE
, stash the changes, rebase to master, then stash pop to re-apply the changes, and make the single commit before force-pushing to the branch. There might be an easier way for more powerful git wizards, but that's how I usually end up doing it.
ended up resetting to commit^, then rebase -i and squash, then force push. Finally down to one commit though. Is github's automatic squash-merging not available for automatic merges?
It doesn't seem apply quite right for some reason. For the git commit message, it should look like this:
feat(core): use epoll when available to support fds > 1023
When epoll is available, and the highest fd in use is > 1023, route through epoll.
Otherwise, use the existing select() behavior so by and large nothing changes.
Closes #266, #171
Easiest way to change the text is git commit --amend
, update it, then force push. Sorry bout the hassle, having a uniform commit style makes it easier to track changes as the automated tool generates helpful changelog entries with linkage, ie, https://github.com/python-zk/kazoo/releases/tag/2.3.1
No, it's my bad. I failed to properly grok the CONTRIBUTING.md guidelines. I'm totally ok with the "hassle" to keep things tidy :)
Thanks for the PR!
Here's my take on the fd > 1023 issue. I'm open to suggestions for the unit test.
Major points: When epoll is available, and the highest fd in use is > 1023, route through epoll. Otherwise, use the existing select() behavior so by and large nothing changes.
closes #266 closes #171