author | Junio C Hamano <junkio@cox.net> | |
Sun, 20 May 2007 07:19:30 +0000 (00:19 -0700) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Sun, 20 May 2007 07:19:30 +0000 (00:19 -0700) |
* maint:
GIT 1.5.1.6
git-svn: don't minimize-url when doing an init that tracks multiple paths
git-svn: avoid crashing svnserve when creating new directories
user-manual: Add section on ignoring files
user-manual: finding commits referencing given file content
user-manual: discourage shared repository
tutorial: revise index introduction
tutorials: add user-manual links
Conflicts:
GIT-VERSION-GEN
RelNotes
GIT 1.5.1.6
git-svn: don't minimize-url when doing an init that tracks multiple paths
git-svn: avoid crashing svnserve when creating new directories
user-manual: Add section on ignoring files
user-manual: finding commits referencing given file content
user-manual: discourage shared repository
tutorial: revise index introduction
tutorials: add user-manual links
Conflicts:
GIT-VERSION-GEN
RelNotes
1 | 2 | |||
---|---|---|---|---|
Documentation/user-manual.txt | patch | | diff1 | | diff2 | | blob | history |
diff --cc Documentation/user-manual.txt
index c4bff474dd0302959a40d31787ce463959f4edb0,534ece464bc5be0e765e0b89a7718be1439463fe..52247aa7134345e94b3c2cc131d33224073f6eeb
Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-link:cvs-migration.txt[git for CVS users] for instructions on how to
+link:cvs-migration.html[git for CVS users] for instructions on how to
set this up.
+ However, while there is nothing wrong with git's support for shared
+ repositories, this mode of operation is not generally recommended,
+ simply because the mode of collaboration that git supports--by
+ exchanging patches and pulling from public repositories--has so many
+ advantages over the central shared repository:
+
+ - Git's ability to quickly import and merge patches allows a
+ single maintainer to process incoming changes even at very
+ high rates. And when that becomes too much, git-pull provides
+ an easy way for that maintainer to delegate this job to other
+ maintainers while still allowing optional review of incoming
+ changes.
+ - Since every developer's repository has the same complete copy
+ of the project history, no repository is special, and it is
+ trivial for another developer to take over maintenance of a
+ project, either by mutual agreement, or because a maintainer
+ becomes unresponsive or difficult to work with.
+ - The lack of a central group of "committers" means there is
+ less need for formal decisions about who is "in" and who is
+ "out".
+
[[setting-up-gitweb]]
Allowing web browsing of a repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~