[Twisted-Python] github, again
tobias.oberstein at tavendo.de
Tue Jun 4 14:43:40 MDT 2013
thanks alot for your detailed explanation of a workflow. For me, that sounds reasonable and workable.
>At some point everyone who's interested will have contributed to the discussion, to the code, and signed off. Then you merge it, using the web UI
So when the code is ready, the feature branch including any accumulated commits (history) will get merged - and not a clean diff against the main repo?
Just asking .. guess there are arguments for both approaches.
>One point of difference that I don't know the best answer to: We tend to each have our own fork of a repo, and to send pull requests into the repo "owned" by the organization. Others (including Github >themselves) just have one repo and anyone can make a branch in that repo and propose it for merging into the master of the same repo. I think I prefer the former, though it has a little more overhead and it >requires people to do a git remote add git at github.com:name/project.git for the other people whose changes you want to track and pull in etc (via git remote update --prune).
+1 for the former (each has it's own repo). p2p scm.
More information about the Twisted-Python