Ceki Gulcu skrev:
That's an excellent question. If git is better at merging and creating forks is easy, Alice could fork logback, work on our branch for a few days or even a few weeks, committing many changes to her forked repository. She could later publicize her repository for others to study. If her changes are deemed interesting, they could be imported back into the "official" logback repository. This is similar to the workflow that would take place on the SVN, except that Alice would not be able to commit her changes locally and nor would she be able to publicize her repository. She would be constrained to patch files.
Ceki, I believe you are so fascinated with the technical capabilities of git, that you may be a bit blinded. What you describe is what a full blown committer would do, not a contributor who would have to undergo peer review before changes was accepted. In such a scenario changes would happen to be small and atomic to allow acceptance/rejection on an individual basis instead of a large monolith of code changes. You may remember that Apple built their Safari browser with the KHTML component from KDE, and their changes was contributed in huge chunks instead of with collaboration between the teams. This did not work well. See e.g. The bitter failure named "safari and khtml" -- http://www.kdedevelopers.org/node/1002 I believe for collaboration to work well, you should avoid forks as much as possible, so your scenario will actually be counterproductive as the technology gets in the way. But again, as I have said before, you are the leader of this project and can choose to do whatever you want. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"