diff options
Diffstat (limited to 'Documentation/tutorial.txt')
| -rw-r--r-- | Documentation/tutorial.txt | 58 |
1 files changed, 47 insertions, 11 deletions
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index cf7ba76..0827056 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -1282,26 +1282,27 @@ fatal: merge program failed `git-merge-one-file` script is called with parameters to describe those three versions, and is responsible to leave the -merge results in the working tree and register it in the index -file. It is a fairly straightforward shell script, and -eventually calls `merge` program from RCS suite to perform the +merge results in the working tree. +It is a fairly straightforward shell script, and +eventually calls `merge` program from RCS suite to perform a file-level 3-way merge. In this case, `merge` detects conflicts, and the merge result with conflict marks is left in -the working tree, while the index file is updated with the -version from the current branch (this is to make `git diff` -useful after this step). This can be seen if you run `ls-files +the working tree.. This can be seen if you run `ls-files --stage` again at this point: ------------ $ git-ls-files --stage 100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example -100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 0 hello +100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello +100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello ------------ -As you can see, there is no unmerged paths in the index file. This is the state of the index file and the working file after `git merge` returns control back to you, leaving the conflicting -merge for you to resolve. +merge for you to resolve. Notice that the path `hello` is still +unmerged, and what you see with `git diff` at this point is +differences since stage 2 (i.e. your version). Publishing your work @@ -1636,14 +1637,49 @@ fast forward. You need to pull and merge those other changes back before you push your work when it happens. +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. + +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. + + Bundling your work together --------------------------- It is likely that you will be working on more than one thing at -a time. It is easy to use those more-or-less independent tasks +a time. It is easy to manage those more-or-less independent tasks using branches with git. -We have already seen how branches work in a previous example, +We have already seen how branches work previously, with "fun and work" example using two branches. The idea is the same if there are more than two branches. Let's say you started out from "master" head, and have some new code in the "master" |