From: Junio C Hamano Date: Sun, 10 Jun 2007 23:45:08 +0000 (-0700) Subject: Merge branch 'maint' X-Git-Tag: v1.5.3-rc0~126 X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/c85d4f166096225fa78a9aec8707c6b834da74cb?ds=inline;hp=-c Merge branch 'maint' * maint: tutorial: use "project history" instead of "changelog" in header Documentation: user-manual todo user-manual: add a missing section ID Fix typo in remote branch example in git user manual user-manual: quick-start updates --- c85d4f166096225fa78a9aec8707c6b834da74cb diff --combined Documentation/user-manual.txt index 957cd00761,780f0f0ee6..0bfa21b3d2 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@@ -27,7 -27,7 +27,7 @@@ $ man git-clon See also <> for a brief overview of git commands, without any explanation. - Also, see <> for ways that you can help make this manual more + Finally, see <> for ways that you can help make this manual more complete. @@@ -154,11 -154,11 +154,11 @@@ Author: Jamal Hadi Salim Signed-off-by: David S. Miller @@@ -167,7 -167,7 +167,7 @@@ index 8be626f..d7aac9d 10064 --- a/Documentation/networking/xfrm_sync.txt +++ b/Documentation/networking/xfrm_sync.txt @@ -47,10 +47,13 @@ aevent_id structure looks like: - + struct xfrm_aevent_id { struct xfrm_usersa_id sa_id; + xfrm_address_t saddr; @@@ -921,6 -921,7 +921,7 @@@ echo "git diff --stat --summary -M v$la and then he just cut-and-pastes the output commands after verifying that they look OK. + [[Finding-comments-with-given-content]] Finding commits referencing a file with given content ----------------------------------------------------- @@@ -1056,7 -1057,7 +1057,7 @@@ $ git sho ------------------------------------------------- As a special shortcut, - + ------------------------------------------------- $ git commit -a ------------------------------------------------- @@@ -1554,7 -1555,7 +1555,7 @@@ history Fortunately, git also keeps a log, called a "reflog", of all the previous values of each branch. So in this case you can still find the -old history using, for example, +old history using, for example, ------------------------------------------------- $ git log master@{1} @@@ -1630,7 -1631,7 +1631,7 @@@ If you decide you want the history back reference pointing to it, for example, a new branch: ------------------------------------------------ -$ git branch recovered-branch 7281251ddd +$ git branch recovered-branch 7281251ddd ------------------------------------------------ Other types of dangling objects (blobs and trees) are also possible, and @@@ -1682,7 -1683,7 +1683,7 @@@ automatically set the default remote br that a branch is created: ------------------------------------------------- - $ git checkout --track -b origin/maint maint + $ git checkout --track -b maint origin/maint ------------------------------------------------- In addition to saving you keystrokes, "git pull" also helps you by @@@ -1793,7 -1794,7 +1794,7 @@@ like this you push your personal repo ------------------> your public repo - ^ | + ^ | | | | you pull | they pull | | @@@ -2359,7 -2360,7 +2360,7 @@@ the result would create a new merge com \ \ a--b--c--m <-- mywork ................................................ - + However, if you prefer to keep the history in mywork a simple series of commits without any merges, you may instead choose to use gitlink:git-rebase[1]: @@@ -2735,7 -2736,7 +2736,7 @@@ must have at least one root, and while root objects together into one project by creating a commit object which has two or more separate roots as its ultimate parents, that's probably just going to confuse people. So aim for the notion of "one root object -per project", even if git itself does not enforce that. +per project", even if git itself does not enforce that. A <> symbolically identifies and can be used to sign other objects. It contains the identifier and type of @@@ -2757,7 -2758,7 +2758,7 @@@ independently of the contents or the ty 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 + + + + . +size> + + . The structured objects can further have their structure and connectivity to other objects verified. This is generally done with @@@ -2954,7 -2955,7 +2955,7 @@@ cache, and the normal operation is to r known tree object, or update/compare it with a live tree that is being developed. If you blow the directory cache away entirely, you generally haven't lost any information as long as you have the name of the tree -that it described. +that it described. At the same time, the index is at the same time also the staging area for creating new trees, and creating a new tree always @@@ -2974,7 -2975,7 +2975,7 @@@ Generally, all "git" operations work o work *purely* on the index file (showing the current state of the index), but most operations move data to and from the index file. Either from the database or from the working directory. Thus there are four -main combinations: +main combinations: [[working-directory-to-index]] working directory -> index @@@ -3437,7 -3438,7 +3438,7 @@@ because you interrupted a "git fetch" w leaving _some_ of the new objects in the object database, but just dangling and useless. -Anyway, once you are sure that you're not interested in any dangling +Anyway, once you are sure that you're not interested in any dangling state, you can just prune all unreachable objects: ------------------------------------------------ @@@ -3448,12 -3449,12 +3449,12 @@@ and they'll be gone. But you should onl repository - it's kind of like doing a filesystem fsck recovery: you don't want to do that while the filesystem is mounted. -(The same is true of "git-fsck" itself, btw - but since -git-fsck never actually *changes* the repository, it just reports -on what it found, git-fsck itself is never "dangerous" to run. -Running it while somebody is actually changing the repository can cause -confusing and scary messages, but it won't actually do anything bad. In -contrast, running "git prune" while somebody is actively changing the +(The same is true of "git-fsck" itself, btw - but since +git-fsck never actually *changes* the repository, it just reports +on what it found, git-fsck itself is never "dangerous" to run. +Running it while somebody is actually changing the repository can cause +confusing and scary messages, but it won't actually do anything bad. In +contrast, running "git prune" while somebody is actively changing the repository is a *BAD* idea). [[birdview-on-the-source-code]] @@@ -3669,11 -3670,11 +3670,11 @@@ itself include::glossary.txt[] [[git-quick-start]] - Appendix A: Git Quick Start - =========================== + Appendix A: Git Quick Reference + =============================== - This is a quick summary of the major commands; the following chapters - will explain how these work in more detail. + This is a quick summary of the major commands; the previous chapters + explain how these work in more detail. [[quick-creating-a-new-repository]] Creating a new repository @@@ -3951,3 -3952,7 +3952,7 @@@ CVS, Subversion, and just imports of se More details on gitweb? Write a chapter on using plumbing and writing scripts. + + Alternates, clone -reference, etc. + + git unpack-objects -r for recovery