Merging Hygiene about streamz HOT 13 OPEN

Committing breaking or WIP code makes lots of sense. I do it all the time. Squash-and-merge allows this kind of workflow during a PR without having it bleed into the final history.

from streamz.

Perhaps we should have a suggestion message on the commits, with rebase instructions, such as:

To squash your commits, please type:
git rebase -i HEAD~N
where N is the number of commits you want to squash. You will be shown a list of commits. Please replace pick with squash with each commit except the latest. When finished, you will be prompted for a commit message. Please write as detailed (but terse) of a commit as you can. Remember to keep the first line short, and add the longer details two lines below.
When finished, you will have to force push to your branch:
git push origin mybranch -f
where origin is the alias to your remove and mybranch is your branch.

Also, tried to conform with discussion here in #66

from streamz.

from streamz.

squash-and-merge works for me. I personally am often guilty of committing breaking code usually as a way to keep track of where I'm at in the middle of a refactor or so I can have other people look at the code, so I'm usually less strict about it, but I could try to be cleaner about that. I guess with squash-and-merge we are guaranteed that all tests pass so long as travis passes on the last commit so I am ok with that.

from streamz.

Do we want a .github/contributing.md to go along with this? (Can we just lift one off of another pydata project?)
Edit: formatting

from streamz.

from streamz.

That's fair (maybe github should have an advanced contributing guide). Do you want to enshrine this information somewhere? If so, where?

from streamz.

from streamz.

I am fine with whichever. Personally, I do like micro commits as they could be useful for code forensics. But the PR's can also serve this (assuming that we can still see comments on outdated diffs after the history has been modified?).

from streamz.

thanks, I was not aware of this!

from streamz.

@jrmlhermitte - that level of git experience is so far above most analysts that you'd be excluding a lot of people and introducing a huge barrier to contribution. As @mrocklin says the GitHub UI can do that for you and that can even be enforced by the repo settings.

from streamz.

I think this issue was really aimed at all those who have merging privileges, since we can do the squash via github and its our responsibility to make sure that the history is as we expect it.

from streamz.

so we've been squashing and merging. Should we write up some developer documentation to close this?

from streamz.