Eric Firing <efiring@...229...> writes:
Fixing OSX makefile by fgb · Pull Request #17 · matplotlib/matplotlib · GitHub
This brings up something that confuses me, together with related
questions, and so might be another topic for this part of the docs:1) How is it that you were able to add commits to a branch of someone
else's fork?
I sent Fernando a pull request:
https://github.com/fgb/matplotlib/pull/1
He merged my commits to his branch, and his pull request was
automatically updated.
2) How should it be decided who merges a pull request, and when?
I think John called for not too much bureaucracy - before git we were
committing things without any review. On the other hand, with git there
is less urgency to get things into master, since if you need someone's
bugfix or feature to continue developing your own stuff, you can pull
from their branch into your own. I think we can depend on everyone's
good judgment.
If we need a guideline, my suggestion is that if someone other than the
author reviews the code and says it is good, or if no-one raises any
issues for some time, it can be merged.
If there are merge conflicts, usually the person who wrote the code is
in the best position to resolve them.
3) Under what circumstances, if any, should a pull request involving
multiple commits be collapsed into a single changeset prior to being
merged and pushed?
If we had a strict policy that tests must pass for every revision (which
I don't think we have had) it would make sense to squash multiple
commits into one if the intermediate commits don't pass the test
suite. Squashing is an instance of a rebase operation, so it should be
avoided for any commits on which someone may have based further work.
···
--
Jouni K. Sepp�nen