Documentation/git-worktree: split technical info from general description

The DESCRIPTION section should provide a high-level overview of linked worktree functionality to bring users up to speed quickly, without overloading them with low-level details, so relocate the technical information to a new DETAILS section. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Eric Sunshine committed Jul 6, 2015 at 13:30 UTC af189b4cbec7f6ff4687c8ca78b2455c1f28923c
1 file changed +36 -34
Documentation/git-worktree.txt
+36 -34
@@ -24,47 +24,18 @@ tree is associated with the repository. This new working tree is called a
24 init" or "git clone". A repository has one main working tree (if it's not a
25 bare repository) and zero or more linked working trees.
26
27 -Each linked working tree has a private sub-directory in the repository's
28 -$GIT_DIR/worktrees directory. The private sub-directory's name is usually
29 -the base name of the linked working tree's path, possibly appended with a
30 -number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the
31 -command `git checkout --to /path/other/test-next next` creates the linked
32 -working tree in `/path/other/test-next` and also creates a
33 -`$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1`
34 -if `test-next` is already taken).
35 -
36 -Within a linked working tree, $GIT_DIR is set to point to this private
37 -directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and
38 -$GIT_COMMON_DIR is set to point back to the main working tree's $GIT_DIR
39 -(e.g. `/path/main/.git`). These settings are made in a `.git` file located at
40 -the top directory of the linked working tree.
41 -
42 -Path resolution via `git rev-parse --git-path` uses either
43 -$GIT_DIR or $GIT_COMMON_DIR depending on the path. For example, in the
44 -linked working tree `git rev-parse --git-path HEAD` returns
45 -`/path/main/.git/worktrees/test-next/HEAD` (not
46 -`/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git
47 -rev-parse --git-path refs/heads/master` uses
48 -$GIT_COMMON_DIR and returns `/path/main/.git/refs/heads/master`,
49 -since refs are shared across all working trees.
50 -
51 -See linkgit:gitrepository-layout[5] for more information. The rule of
52 -thumb is do not make any assumption about whether a path belongs to
53 -$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something
54 -inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.
55 -
27 When you are done with a linked working tree you can simply delete it.
57 -The working tree's entry in the repository's $GIT_DIR/worktrees
58 -directory will eventually be removed automatically (see
28 +The working tree's administrative files in the repository (see
29 +"DETAILS" below) will eventually be removed automatically (see
30 `gc.pruneworktreesexpire` in linkgit::git-config[1]), or you can run
31 `git worktree prune` in the main or any linked working tree to
61 -clean up any stale entries in $GIT_DIR/worktrees.
32 +clean up any stale administrative files.
33
34 If you move a linked working directory to another file system, or
35 within a file system that does not support hard links, you need to run
36 at least one git command inside the linked working directory
66 -(e.g. `git status`) in order to update its entry in $GIT_DIR/worktrees
67 -so that it does not get automatically removed.
37 +(e.g. `git status`) in order to update its administrative files in the
38 +repository so that they do not get automatically pruned.
39
40 To prevent a $GIT_DIR/worktrees entry from from being pruned (which
41 can be useful in some situations, such as when the
@@ -97,6 +68,37 @@ OPTIONS
68 --expire <time>::
69 With `prune`, only expire unused worktrees older than <time>.
70
71 +DETAILS
72 +-------
73 +Each linked working tree has a private sub-directory in the repository's
74 +$GIT_DIR/worktrees directory. The private sub-directory's name is usually
75 +the base name of the linked working tree's path, possibly appended with a
76 +number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the
77 +command `git checkout --to /path/other/test-next next` creates the linked
78 +working tree in `/path/other/test-next` and also creates a
79 +`$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1`
80 +if `test-next` is already taken).
81 +
82 +Within a linked working tree, $GIT_DIR is set to point to this private
83 +directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and
84 +$GIT_COMMON_DIR is set to point back to the main working tree's $GIT_DIR
85 +(e.g. `/path/main/.git`). These settings are made in a `.git` file located at
86 +the top directory of the linked working tree.
87 +
88 +Path resolution via `git rev-parse --git-path` uses either
89 +$GIT_DIR or $GIT_COMMON_DIR depending on the path. For example, in the
90 +linked working tree `git rev-parse --git-path HEAD` returns
91 +`/path/main/.git/worktrees/test-next/HEAD` (not
92 +`/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git
93 +rev-parse --git-path refs/heads/master` uses
94 +$GIT_COMMON_DIR and returns `/path/main/.git/refs/heads/master`,
95 +since refs are shared across all working trees.
96 +
97 +See linkgit:gitrepository-layout[5] for more information. The rule of
98 +thumb is do not make any assumption about whether a path belongs to
99 +$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something
100 +inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.
101 +
102 BUGS
103 ----
104 Multiple checkout support for submodules is incomplete. It is NOT