[logback-dev] Git as a version control system?
Thorbjoern Ravn Andersen
ravn at runjva.com
Fri Aug 7 17:36:37 CEST 2009
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
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" --
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!"
More information about the logback-dev