X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=README;h=cee7e435d7e28bb09c9dc39abf50e84358de7a92;hb=74237d6236d7e32f69469ff26df3f3bb3875f523;hp=62c3b0c294215af3f0f206307b89c00e26e6802b;hpb=fc1a4207b025ddd79d6383ed06f786c8a6f03289;p=git.git diff --git a/README b/README index 62c3b0c2..cee7e435 100644 --- a/README +++ b/README @@ -35,7 +35,7 @@ the object (i.e. how it is used, and how it can refer to other objects). There are currently four different object types: "blob", "tree", "commit" and "tag". -A "blob" object cannot refer to any other object, and is, like the tag +A "blob" object cannot refer to any other object, and is, like the type implies, a pure storage object containing some user data. It is used to actually store the file data, i.e. a blob object is associated with some particular version of some file. @@ -64,7 +64,7 @@ symbolic name (of course!) and, optionally, a signature. Regardless of object type, all objects share the following characteristics: they are all deflated with zlib, and have a header -that not only specifies their tag, but also provides size information +that not only specifies their type, but also provides size information about the data in the object. It's worth noting that the SHA1 hash that is used to name the object is the hash of the original data plus this header, so `sha1sum` 'file' does not match the object name @@ -76,12 +76,12 @@ As a result, the general consistency of an object can always be tested independently of the contents or the type of the object: all objects can be validated by verifying that (a) their hashes match the content of the file and (b) the object successfully inflates to a stream of bytes that -forms a sequence of + + + + + + . The structured objects can further have their structure and connectivity to other objects verified. This is generally done with -the `git-fsck-cache` program, which generates a full dependency graph +the `git-fsck-objects` program, which generates a full dependency graph of all objects, and verifies their internal consistency (in addition to just verifying their superficial consistency through the hash). @@ -104,8 +104,8 @@ object. The object is totally independent of its location in the directory tree, and renaming a file does not change the object that file is associated with in any way. -A blob is typically created when link:git-update-cache.html[git-update-cache] -is run, and its data can be accessed by link:git-cat-file.html[git-cat-file]. +A blob is typically created when gitlink:git-update-index[1] +is run, and its data can be accessed by gitlink:git-cat-file[1]. Tree Object ~~~~~~~~~~~ @@ -143,9 +143,9 @@ involved), you can see trivial renames or permission changes by noticing that the blob stayed the same. However, renames with data changes need a smarter "diff" implementation. -A tree is created with link:git-write-tree.html[git-write-tree] and -its data can be accessed by link:git-ls-tree.html[git-ls-tree]. -Two trees can be compared with link:git-diff-tree.html[git-diff-tree]. +A tree is created with gitlink:git-write-tree[1] and +its data can be accessed by gitlink:git-ls-tree[1]. +Two trees can be compared with gitlink:git-diff-tree[1]. Commit Object ~~~~~~~~~~~~~ @@ -169,8 +169,8 @@ implicit in the trees involved (the result tree, and the result trees of the parents), and describing that makes no sense in this idiotic file manager. -A commit is created with link:git-commit-tree.html[git-commit-tree] and -its data can be accessed by link:git-cat-file.html[git-cat-file]. +A commit is created with gitlink:git-commit-tree[1] and +its data can be accessed by gitlink:git-cat-file[1]. Trust ~~~~~ @@ -215,10 +215,10 @@ Note that despite the tag features, "git" itself only handles content integrity; the trust framework (and signature provision and verification) has to come from outside. -A tag is created with link:git-mktag.html[git-mktag], -its data can be accessed by link:git-cat-file.html[git-cat-file], +A tag is created with gitlink:git-mktag[1], +its data can be accessed by gitlink:git-cat-file[1], and the signature can be verified by -link:git-verify-tag-script.html[git-verify-tag]. +gitlink:git-verify-tag[1]. The "index" aka "Current Directory Cache" @@ -286,18 +286,18 @@ main combinations: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You update the index with information from the working directory with -the link:git-update-cache.html[git-update-cache] command. You +the gitlink:git-update-index[1] command. You generally update the index information by just specifying the filename you want to update, like so: - git-update-cache filename + git-update-index filename but to avoid common mistakes with filename globbing etc, the command will not normally add totally new entries or remove old entries, i.e. it will normally just update existing cache entries. To tell git that yes, you really do realize that certain files no -longer exist in the archive, or that new files should be added, you +longer exist, or that new files should be added, you should use the `--remove` and `--add` flags respectively. NOTE! A `--remove` flag does 'not' mean that subsequent filenames will @@ -307,7 +307,7 @@ removed. The only thing `--remove` means is that update-cache will be considering a removed file to be a valid thing, and if the file really does not exist any more, it will update the index accordingly. -As a special case, you can also do `git-update-cache --refresh`, which +As a special case, you can also do `git-update-index --refresh`, which will refresh the "stat" information of each index to match the current stat information. It will 'not' update the object status itself, and it will only update the fields that are used to quickly test whether @@ -347,18 +347,18 @@ You update your working directory from the index by "checking out" files. This is not a very common operation, since normally you'd just keep your files updated, and rather than write to your working directory, you'd tell the index files about the changes in your -working directory (i.e. `git-update-cache`). +working directory (i.e. `git-update-index`). However, if you decide to jump to a new version, or check out somebody else's version, or just restore a previous tree, you'd populate your index file with read-tree, and then you need to check out the result with - git-checkout-cache filename + git-checkout-index filename or, if you want to check out all of the index, use `-a`. -NOTE! git-checkout-cache normally refuses to overwrite old files, so +NOTE! git-checkout-index normally refuses to overwrite old files, so if you have an old version of the tree already checked out, you will need to use the "-f" flag ('before' the "-a" flag or the filename) to 'force' the checkout. @@ -396,15 +396,55 @@ git-commit-tree will return the name of the object that represents that commit, and you should save it away for later use. Normally, you'd commit a new `HEAD` state, and while git doesn't care where you save the note about that state, in practice we tend to just write the -result to the file `.git/HEAD`, so that we can always see what the -last committed state was. +result to the file pointed at by `.git/HEAD`, so that we can always see +what the last committed state was. + +Here is an ASCII art by Jon Loeliger that illustrates how +various pieces fit together. + +------------ + + commit-tree + commit obj + +----+ + | | + | | + V V + +-----------+ + | Object DB | + | Backing | + | Store | + +-----------+ + ^ + write-tree | | + tree obj | | + | | read-tree + | | tree obj + V + +-----------+ + | Index | + | "cache" | + +-----------+ + update-index ^ + blob obj | | + | | + checkout-index -u | | checkout-index + stat | | blob obj + V + +-----------+ + | Working | + | Directory | + +-----------+ + +------------ + 6) Examining the data ~~~~~~~~~~~~~~~~~~~~~ You can examine the data represented in the object database and the index with various helper tools. For every object, you can use -link:git-cat-file.html[git-cat-file] to examine details about the +gitlink:git-cat-file[1] to examine details about the object: git-cat-file -t @@ -424,7 +464,7 @@ tend to be small and fairly self-explanatory. In particular, if you follow the convention of having the top commit name in `.git/HEAD`, you can do - git-cat-file commit $(cat .git/HEAD) + git-cat-file commit HEAD to see what the top commit was. @@ -475,8 +515,11 @@ index file, and you can just write the result out with Historical note. We did not have `-u` facility when this section was first written, so we used to warn that the merge is done in the index file, not in your -working directory, and your working directory will no longer match your -index. +working tree, and your working tree will not match your +index after this step. +This is no longer true. The above command, thanks to `-u` +option, updates your working tree with the merge results for +paths that have been trivially merged. 8) Merging multiple trees, continued @@ -530,17 +573,17 @@ the merge result makes sense, you can tell git what the final merge result for this file is by: mv -f hello.c~2 hello.c - git-update-cache hello.c + git-update-index hello.c -When a path is in unmerged state, running `git-update-cache` for +When a path is in unmerged state, running `git-update-index` for that path tells git to mark the path resolved. The above is the description of a git merge at the lowest level, to help you understand what conceptually happens under the hood. In practice, nobody, not even git itself, uses three `git-cat-file` -for this. There is `git-merge-cache` program that extracts the -stages to temporary files and calls a `merge` script on it +for this. There is `git-merge-index` program that extracts the +stages to temporary files and calls a "merge" script on it: - git-merge-cache git-merge-one-file-script hello.c + git-merge-index git-merge-one-file hello.c and that is what higher level `git resolve` is implemented with.