Terry, 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 >g...@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. /Tobias _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
