On May 7, Michael Sperber wrote:
>
> Unlike SVN, git commits only work wholesale: In SVN, you can commit
> to a bunch of files as long as *those files* are up to date, even if
> the rest of the tree isn't - in this case, the commit refers to the
> latest version on the server, unlike git, where the commit refers to
> the latest version the developer has. So, with git, if you have
> many developers, you can get "merge churn" where you have to merge
> repeatedly (and idefinitely) to get your own commits in. That's why
> big projects are pull-based with designated integrators who push to
> the "main repository".
Ah, yes, I did consider that too. If we get there, then a quick
temporary solution is simple: just cut down the number of people with
access to the repository, and have others pipe in commits through
them. For a systematic solution, there are also a number of tools
(like gerrit) that will run merges on the server, and that would work
as longer term solution. In any case this is all a theoretical
problem at this point.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
