cvs-migration documentation update
PATCH 1/1 cvs-migration documentation update
Here's some changes to the cvs-migration.txt. As usual, in my attempt to make things clearer someone may have found I've made them less so, or I may have just gotten something wrong; so any review is welcomed.
I can break up this sort of thing into smaller steps if preferred, the monolothic patch is just a bit simpler for me for this sort of thing.
I moved the material describing shared repository management from core-tutorial.txt to cvs-migration.txt, where it seems more appropriate, and combined two sections to eliminate some redundancy.
I also revised the earlier sections of cvs-migration.txt, mainly trying to make it more concise.
I've left the last section of cvs-migration.txt (on CVS annotate alternatives) alone for now.
---
Documentation/core-tutorial.txt | 118 ----------------- Documentation/cvs-migration.txt | 276 +++++++++++++++++++++++---------------- 2 files changed, 167 insertions(+), 227 deletions(-)
bfa569527ebfa0388103c0619f15a2ee71ef3624
Documentation/core-tutorial.txt +1 -117
@@ -1623,123 +1623,7 @@ suggested in the previous section may be have to worry. git supports "shared public repository" style of cooperation you are probably more familiar with as well. -For this, set up a public repository on a machine that is -reachable via SSH by people with "commit privileges". Put the -committers in the same user group and make the repository -writable by that group. Make sure their umasks are set up to -allow group members to write into directories other members -have created. - -You, as an individual committer, then: - -- First clone the shared repository to a local repository: ------------------------------------------------- -$ git clone repo.shared.xz:/pub/scm/project.git/ my-project -$ cd my-project -$ hack away ------------------------------------------------- - -- Merge the work others might have done while you were hacking - away: ------------------------------------------------- -$ git pull origin -$ test the merge result ------------------------------------------------- -[NOTE] -================================ -The first `git clone` would have placed the following in -`my-project/.git/remotes/origin` file, and that's why this and -the next step work. ------------- -URL: repo.shared.xz:/pub/scm/project.git/ my-project -Pull: master:origin ------------- -================================ - -- push your work as the new head of the shared - repository. ------------------------------------------------- -$ git push origin master ------------------------------------------------- -If somebody else pushed into the same shared repository while -you were working locally, `git push` in the last step would -complain, telling you that the remote `master` head does not -fast forward. You need to pull and merge those other changes -back before you push your work when it happens. - -The `git push` command without any explicit refspec parameter -pushes the refs that exist both in the local repository and the -remote repository. So the last `push` can be done with either -one of these: ------------- -$ git push origin -$ git push repo.shared.xz:/pub/scm/project.git/ ------------- -as long as the shared repository does not have any branches -other than `master`. -[NOTE] -============ -If you created your shared repository by cloning from somewhere -else, you may have the `origin` branch. Your developers -typically do not use that branch; remove it. Otherwise, that -would be pushed back by the `git push origin` because your -developers' repository would surely have `origin` branch to keep -track of the shared repository, and would be counted as "exist -on both ends". -============ - -Advanced Shared Repository Management -------------------------------------- - -Being able to push into a shared repository means being able to -write into it. If your developers are coming over the network, -this means you, as the repository administrator, need to give -each of them an SSH access to the shared repository machine. - -In some cases, though, you may not want to give a normal shell -account to them, but want to restrict them to be able to only -do `git push` into the repository and nothing else. - -You can achieve this by setting the login shell of your -developers on the shared repository host to `git-shell` program. - -[NOTE] -Most likely you would also need to list `git-shell` program in -`/etc/shells` file. - -This restricts the set of commands that can be run from incoming -SSH connection for these users to only `receive-pack` and -`upload-pack`, so the only thing they can do are `git fetch` and -`git push`. - -You still need to create UNIX user accounts for each developer, -and put them in the same group. Make sure that the repository -shared among these developers is writable by that group. - -. Initializing the shared repository with `git-init-db --shared` -helps somewhat. - -. Run the following in the shared repository: -+ ------------- -$ chgrp -R $group repo.git -$ find repo.git -type d -print | xargs chmod ug+rwx,g+s -$ GIT_DIR=repo.git git repo-config core.sharedrepository true ------------- - -The above measures make sure that directories lazily created in -`$GIT_DIR` are writable by group members. You, as the -repository administrator, are still responsible to make sure -your developers belong to that shared repository group and set -their umask to a value no stricter than 027 (i.e. at least allow -reading and searching by group members). - -You can implement finer grained branch policies using update -hooks. There is a document ("control access to branches") in -Documentation/howto by Carl Baldwin and JC outlining how to (1) -limit access to branch per user, (2) forbid overwriting existing -tags. - +See link:cvs-migration.txt[git for CVS users] for the details. Bundling your work together ---------------------------
Documentation/cvs-migration.txt +166 -110
292 lines not on this page · raw message
Signature · 1 line
0.99.8b.g3480-dirty
Quoted 3 lines · J. Bruce Fields
Here's some changes to the cvs-migration.txt. As usual, in my attempt to make things clearer someone may have found I've made them less so, or I may have just gotten something wrong; so any review is welcomed.
Again, thanks for doing this.
Quoted 3 lines
I moved the material describing shared repository management from core-tutorial.txt to cvs-migration.txt, where it seems more appropriate, and combined two sections to eliminate some redundancy.
Seems sensible.
Quoted 6 lines
Documentation/cvs-migration.txt +0
-0@@ -1,126 +1,182 @@ git for CVS users
Documentation/cvs-migration.txt line 11
Quoted 10 lines
Documentation/cvs-migration.txt +0
-8================= -..., and the -first step to recovery is admitting you have a problem. The fact that -you are reading this file means that you may be well on that path -already. - -The thing about CVS is that it absolutely sucks... - -One particular suckage of CVS is very hard to work around: CVS is...
Somehow I miss the above two paragraphs and a half ;-). But listing the differences as bullet points as you did makes things much clearer. I like it.
Documentation/cvs-migration.txt line 143
Quoted 5 lines
Documentation/cvs-migration.txt +5
-0+------------------------------------------------ +$ git push origin master +------------------------------------------------ + +If some else has updated the repository more recently, `git push`, like
some else?
Quoted 7 lines · Junio C Hamano
Quoted 3 lines · J. Bruce Fields
Here's some changes to the cvs-migration.txt. As usual, in my attempt to make things clearer someone may have found I've made them less so, or I may have just gotten something wrong; so any review is welcomed.
Again, thanks for doing this.
Hey, it's fun.
Quoted 10 lines
Documentation/cvs-migration.txt
Quoted 8 lines
-..., and the
Documentation/cvs-migration.txt +0
-7-first step to recovery is admitting you have a problem. The fact that -you are reading this file means that you may be well on that path -already. - -The thing about CVS is that it absolutely sucks... - -One particular suckage of CVS is very hard to work around: CVS is...Somehow I miss the above two paragraphs and a half ;-).
Hah. Yes, understood. But I figured a reader trying to migrate away from CVS is more painfully aware of the above than anyone, so better to just get out of their way and let them get on with it....
Quoted 2 lines
But listing the differences as bullet points as you did makes things much clearer. I like it.
OK! Good.
Quoted 3 lines
Quoted 1 line
+If some else has updated the repository more recently,
git push, likesome else?
Whoops, thanks for noticing, should be "someone", obviously.
Let me know if you'd like a revised patch.--b.