[logback-dev] Git as a version control system?

[Thorbjoern Ravn Andersen]

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!"