├── .gitignore ├── Git.docset ├── Contents │ ├── Resources │ │ ├── Documents │ │ │ ├── docs │ │ │ │ ├── git-add.html │ │ │ │ ├── git-am.html │ │ │ │ ├── git-apply.html │ │ │ │ ├── git-archive.html │ │ │ │ ├── git-bisect.html │ │ │ │ ├── git-blame.html │ │ │ │ ├── git-branch.html │ │ │ │ ├── git-cat-file.html │ │ │ │ ├── git-checkout.html │ │ │ │ ├── git-cherry-pick.html │ │ │ │ ├── git-clean.html │ │ │ │ ├── git-clone.html │ │ │ │ ├── git-commit-tree.html │ │ │ │ ├── git-commit.html │ │ │ │ ├── git-config.html │ │ │ │ ├── git-count-objects.html │ │ │ │ ├── git-daemon.html │ │ │ │ ├── git-describe.html │ │ │ │ ├── git-diff-index.html │ │ │ │ ├── git-diff.html │ │ │ │ ├── git-fast-import.html │ │ │ │ ├── git-fetch.html │ │ │ │ ├── git-filter-branch.html │ │ │ │ ├── git-format-patch.html │ │ │ │ ├── git-fsck.html │ │ │ │ ├── git-gc.html │ │ │ │ ├── git-grep.html │ │ │ │ ├── git-hash-object.html │ │ │ │ ├── git-help.html │ │ │ │ ├── git-init.html │ │ │ │ ├── git-instaweb.html │ │ │ │ ├── git-log.html │ │ │ │ ├── git-merge-base.html │ │ │ │ ├── git-merge.html │ │ │ │ ├── git-mergetool.html │ │ │ │ ├── git-mv.html │ │ │ │ ├── git-pull.html │ │ │ │ ├── git-push.html │ │ │ │ ├── git-read-tree.html │ │ │ │ ├── git-rebase.html │ │ │ │ ├── git-reflog.html │ │ │ │ ├── git-remote.html │ │ │ │ ├── git-request-pull.html │ │ │ │ ├── git-reset.html │ │ │ │ ├── git-rev-list.html │ │ │ │ ├── git-rev-parse.html │ │ │ │ ├── git-rm.html │ │ │ │ ├── git-send-email.html │ │ │ │ ├── git-shortlog.html │ │ │ │ ├── git-show-ref.html │ │ │ │ ├── git-show.html │ │ │ │ ├── git-stash.html │ │ │ │ ├── git-status.html │ │ │ │ ├── git-submodule.html │ │ │ │ ├── git-svn.html │ │ │ │ ├── git-symbolic-ref.html │ │ │ │ ├── git-tag.html │ │ │ │ ├── git-update-index.html │ │ │ │ ├── git-update-ref.html │ │ │ │ ├── git-update-server-info.html │ │ │ │ ├── git-verify-pack.html │ │ │ │ └── git-write-tree.html │ │ │ └── index.html │ │ └── docSet.dsidx │ └── info.plist └── icon.png ├── README.md ├── git-gendoc2dash.py └── screenshot.png /.gitignore: -------------------------------------------------------------------------------- 1 | *.py[cod] 2 | 3 | # C extensions 4 | *.so 5 | 6 | # Packages 7 | *.egg 8 | *.egg-info 9 | dist 10 | build 11 | eggs 12 | parts 13 | bin 14 | var 15 | sdist 16 | develop-eggs 17 | .installed.cfg 18 | lib 19 | lib64 20 | __pycache__ 21 | 22 | # Installer logs 23 | pip-log.txt 24 | 25 | # Unit test / coverage reports 26 | .coverage 27 | .tox 28 | nosetests.xml 29 | 30 | # Translations 31 | *.mo 32 | 33 | # Mr Developer 34 | .mr.developer.cfg 35 | .project 36 | .pydevproject 37 | -------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-am.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git am [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8]
 16 | [--3way] [--interactive] [--committer-date-is-author-date]
 17 | [--ignore-date] [--ignore-space-change | --ignore-whitespace]
 18 | [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
 19 | [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet]
 20 | [--[no-]scissors]
 21 | [(<mbox> | <Maildir>)...]
 22 | git am (--continue | --skip | --abort)
23 |
24 |
25 |
26 |

DESCRIPTION

27 |
28 |

Splits mail messages in a mailbox into commit log message, 29 | authorship information and patches, and applies them to the 30 | current branch. 31 |

32 |
33 |
34 |
35 |

OPTIONS

36 |
37 |
38 |
(<mbox>|<Maildir>)...
39 |

The list of mailbox files to read patches from. If you do not 40 | supply this argument, the command reads from the standard input. 41 | If you supply directories, they will be treated as Maildirs.

42 |
-s
43 |
--signoff
44 |

Add a Signed-off-by: line to the commit message, using 45 | the committer identity of yourself.

46 |
-k
47 |
--keep
48 |

Pass -k flag to git mailinfo (see git-mailinfo(1)).

49 |
--keep-non-patch
50 |

Pass -b flag to git mailinfo (see git-mailinfo(1)).

51 |
--[no-]keep-cr
52 |

With --keep-cr, call git mailsplit (see git-mailsplit(1)) 53 | with the same option, to prevent it from stripping CR at the end of 54 | lines. am.keepcr configuration variable can be used to specify the 55 | default behaviour. --no-keep-cr is useful to override am.keepcr.

56 |
-c
57 |
--scissors
58 |

Remove everything in body before a scissors line (see 59 | git-mailinfo(1)).

60 |
--no-scissors
61 |

Ignore scissors lines (see git-mailinfo(1)).

62 |
-q
63 |
--quiet
64 |

Be quiet. Only print error messages.

65 |
-u
66 |
--utf8
67 |

Pass -u flag to git mailinfo (see git-mailinfo(1)). 68 | The proposed commit log message taken from the e-mail 69 | is re-coded into UTF-8 encoding (configuration variable 70 | i18n.commitencoding can be used to specify project's 71 | preferred encoding if it is not UTF-8).

72 |

73 |
74 |
75 |

This was optional in prior versions of git, but now it is the 76 | default. You can use --no-utf8 to override this. 77 |

78 |
79 |
80 |
--no-utf8
81 |

Pass -n flag to git mailinfo (see 82 | git-mailinfo(1)).

83 |
-3
84 |
--3way
85 |

When the patch does not apply cleanly, fall back on 86 | 3-way merge if the patch records the identity of blobs 87 | it is supposed to apply to and we have those blobs 88 | available locally.

89 |
--ignore-date
90 |
--ignore-space-change
91 |
--ignore-whitespace
92 |
--whitespace=<option>
93 |
-C<n>
94 |
-p<n>
95 |
--directory=<dir>
96 |
--exclude=<path>
97 |
--include=<path>
98 |
--reject
99 |

These flags are passed to the git apply (see git-apply(1)) 100 | program that applies 101 | the patch.

102 |
-i
103 |
--interactive
104 |

Run interactively.

105 |
--committer-date-is-author-date
106 |

By default the command records the date from the e-mail 107 | message as the commit author date, and uses the time of 108 | commit creation as the committer date. This allows the 109 | user to lie about the committer date by using the same 110 | value as the author date.

111 |
--ignore-date
112 |

By default the command records the date from the e-mail 113 | message as the commit author date, and uses the time of 114 | commit creation as the committer date. This allows the 115 | user to lie about the author date by using the same 116 | value as the committer date.

117 |
--skip
118 |

Skip the current patch. This is only meaningful when 119 | restarting an aborted patch.

120 |
--continue
121 |
-r
122 |
--resolved
123 |

After a patch failure (e.g. attempting to apply 124 | conflicting patch), the user has applied it by hand and 125 | the index file stores the result of the application. 126 | Make a commit using the authorship and commit log 127 | extracted from the e-mail message and the current index 128 | file, and continue.

129 |
--resolvemsg=<msg>
130 |

When a patch failure occurs, <msg> will be printed 131 | to the screen before exiting. This overrides the 132 | standard message informing you to use --continue 133 | or --skip to handle the failure. This is solely 134 | for internal use between git rebase and git am.

135 |
--abort
136 |

Restore the original branch and abort the patching operation.

137 |
138 |
139 |
140 |
141 |

DISCUSSION

142 |
143 |

The commit author name is taken from the "From: " line of the 144 | message, and commit author date is taken from the "Date: " line 145 | of the message. The "Subject: " line is used as the title of 146 | the commit, after stripping common prefix "[PATCH <anything>]". 147 | The "Subject: " line is supposed to concisely describe what the 148 | commit is about in one line of text. 149 |

150 |
151 |
152 |

"From: " and "Subject: " lines starting the body override the respective 153 | commit author name and title values taken from the headers. 154 |

155 |
156 |
157 |

The commit message is formed by the title taken from the 158 | "Subject: ", a blank line and the body of the message up to 159 | where the patch begins. Excess whitespace at the end of each 160 | line is automatically stripped. 161 |

162 |
163 |
164 |

The patch is expected to be inline, directly following the 165 | message. Any line that is of the form: 166 |

167 |
168 |
169 |
    170 |

  • three-dashes and end-of-line, or

    • 171 |

  • a line that begins with "diff -", or

    • 172 |

  • a line that begins with "Index: "

    • 173 |
174 |
175 |
176 |

is taken as the beginning of a patch, and the commit log message 177 | is terminated before the first occurrence of such a line. 178 |

179 |
180 |
181 |

When initially invoking git am, you give it the names of the mailboxes 182 | to process. Upon seeing the first patch that does not apply, it 183 | aborts in the middle. You can recover from this in one of two ways: 184 |

185 |
186 |
187 |
    188 |

  1. skip the current patch by re-running the command with the --skip 189 | option.

    2. 190 |

  2. hand resolve the conflict in the working directory, and update 191 | the index file to bring it into a state that the patch should 192 | have produced. Then run the command with the --continue option.

    3. 193 |
194 |
195 |
196 |

The command refuses to process new mailboxes until the current 197 | operation is finished, so if you decide to start over from scratch, 198 | run git am --abort before running the command with mailbox 199 | names. 200 |

201 |
202 |
203 |

Before any patches are applied, ORIG_HEAD is set to the tip of the 204 | current branch. This is useful if you have problems with multiple 205 | commits, like running git am on the wrong branch or an error in the 206 | commits that is more easily fixed by changing the mailbox (e.g. 207 | errors in the "From:" lines). 208 |

209 |
210 |
211 |
212 |

SEE ALSO

213 |
214 |

git-apply(1). 215 |

216 |
217 |
218 |
219 |

GIT

220 |
221 |

Part of the git(1) suite 222 |

223 |
224 |
225 |
226 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-archive.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git archive [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
 16 | [-o <file> | --output=<file>] [--worktree-attributes]
 17 | [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
 18 | [<path>...]
19 |
20 |
21 |
22 |
23 |

DESCRIPTION

24 |
25 |

Creates an archive of the specified format containing the tree 26 | structure for the named tree, and writes it out to the standard 27 | output. If <prefix> is specified it is 28 | prepended to the filenames in the archive. 29 |

30 |
31 |
32 |

git archive behaves differently when given a tree ID versus when 33 | given a commit ID or tag ID. In the first case the current time is 34 | used as the modification time of each file in the archive. In the latter 35 | case the commit time as recorded in the referenced commit object is 36 | used instead. Additionally the commit ID is stored in a global 37 | extended pax header if the tar format is used; it can be extracted 38 | using git get-tar-commit-id. In ZIP files it is stored as a file 39 | comment. 40 |

41 |
42 |
43 |
44 |
45 |

OPTIONS

46 |
47 |
48 |
--format=<fmt>
49 |

Format of the resulting archive: tar or zip. If this option 50 | is not given, and the output file is specified, the format is 51 | inferred from the filename if possible (e.g. writing to "foo.zip" 52 | makes the output to be in the zip format). Otherwise the output 53 | format is tar.

54 |
-l
55 |
--list
56 |

Show all available formats.

57 |
-v
58 |
--verbose
59 |

Report progress to stderr.

60 |
--prefix=<prefix>/
61 |

Prepend <prefix>/ to each filename in the archive.

62 |
-o <file>
63 |
--output=<file>
64 |

Write the archive to <file> instead of stdout.

65 |
--worktree-attributes
66 |

Look for attributes in .gitattributes files in the working tree 67 | as well (see [ATTRIBUTES]).

68 |
<extra>
69 |

This can be any options that the archiver backend understands. 70 | See next section.

71 |
--remote=<repo>
72 |

Instead of making a tar archive from the local repository, 73 | retrieve a tar archive from a remote repository.

74 |
--exec=<git-upload-archive>
75 |

Used with --remote to specify the path to the 76 | git-upload-archive on the remote side.

77 |
<tree-ish>
78 |

The tree or commit to produce an archive for.

79 |
<path>
80 |

Without an optional path parameter, all files and subdirectories 81 | of the current working directory are included in the archive. 82 | If one or more paths are specified, only these are included.

83 |
84 |
85 |
86 |
87 |
88 |

BACKEND EXTRA OPTIONS

89 |
90 |

zip

91 |
92 |
93 |
-0
94 |

Store the files instead of deflating them.

95 |
-9
96 |

Highest and slowest compression level. You can specify any 97 | number from 1 to 9 to adjust compression speed and ratio.

98 |
99 |
100 |
101 |
102 |
103 |
104 |

CONFIGURATION

105 |
106 |
107 |
tar.umask
108 |

This variable can be used to restrict the permission bits of 109 | tar archive entries. The default is 0002, which turns off the 110 | world write bit. The special value "user" indicates that the 111 | archiving user's umask will be used instead. See umask(2) for 112 | details. If --remote is used then only the configuration of 113 | the remote repository takes effect.

114 |
tar.<format>.command
115 |

This variable specifies a shell command through which the tar 116 | output generated by git archive should be piped. The command 117 | is executed using the shell with the generated tar file on its 118 | standard input, and should produce the final output on its 119 | standard output. Any compression-level options will be passed 120 | to the command (e.g., "-9"). An output file with the same 121 | extension as <format> will be use this format if no other 122 | format is given.

123 |

124 |
125 |
126 |

The "tar.gz" and "tgz" formats are defined automatically and default to 127 | gzip -cn. You may override them with custom commands. 128 |

129 |
130 |
131 |
tar.<format>.remote
132 |

If true, enable <format> for use by remote clients via 133 | git-upload-archive(1). Defaults to false for 134 | user-defined formats, but true for the "tar.gz" and "tgz" 135 | formats.

136 |
137 |
138 |
139 |
140 |
141 | 142 |

ATTRIBUTES

143 |
144 |
145 |
export-ignore
146 |

Files and directories with the attribute export-ignore won't be 147 | added to archive files. See gitattributes(5) for details.

148 |
export-subst
149 |

If the attribute export-subst is set for a file then Git will 150 | expand several placeholders when adding this file to an archive. 151 | See gitattributes(5) for details.

152 |
153 |
154 |
155 |

Note that attributes are by default taken from the .gitattributes files 156 | in the tree that is being archived. If you want to tweak the way the 157 | output is generated after the fact (e.g. you committed without adding an 158 | appropriate export-ignore in its .gitattributes), adjust the checked out 159 | .gitattributes file as necessary and use --worktree-attributes 160 | option. Alternatively you can keep necessary attributes that should apply 161 | while archiving any tree in your $GIT_DIR/info/attributes file. 162 |

163 |
164 |
165 |
166 |
167 |

EXAMPLES

168 |
169 |
170 |
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)
171 |

Create a tar archive that contains the contents of the 172 | latest commit on the current branch, and extract it in the 173 | /var/tmp/junk directory.

174 |
git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz
175 |

Create a compressed tarball for v1.4.0 release.

176 |
git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz
177 |

Same as above, but using the builtin tar.gz handling.

178 |
git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0
179 |

Same as above, but the format is inferred from the output file.

180 |
git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip >git-1.4.0.tar.gz
181 |

Create a compressed tarball for v1.4.0 release, but without a 182 | global extended pax header.

183 |
git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip
184 |

Put everything in the current head's Documentation/ directory 185 | into git-1.4.0-docs.zip, with the prefix git-docs/.

186 |
git archive -o latest.zip HEAD
187 |

Create a Zip archive that contains the contents of the latest 188 | commit on the current branch. Note that the output format is 189 | inferred by the extension of the output file.

190 |
git config tar.tar.xz.command "xz -c"
191 |

Configure a "tar.xz" format for making LZMA-compressed tarfiles. 192 | You can use it specifying --format=tar.xz, or by creating an 193 | output file like -o foo.tar.xz.

194 |
195 |
196 |
197 |
198 |
199 |

SEE ALSO

200 |
201 |

gitattributes(5) 202 |

203 |
204 |
205 |
206 |
207 |

GIT

208 |
209 |

Part of the git(1) suite 210 |

211 |
212 |
213 |
214 |
215 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-cat-file.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git cat-file (-t | -s | -e | -p | <type> | --textconv ) <object>
 16 | git cat-file (--batch | --batch-check) < <list-of-objects>
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

In its first form, the command provides the content or the type of an object in 23 | the repository. The type is required unless -t or -p is used to find the 24 | object type, or -s is used to find the object size, or --textconv is used 25 | (which implies type "blob"). 26 |

27 |
28 |
29 |

In the second form, a list of objects (separated by linefeeds) is provided on 30 | stdin, and the SHA-1, type, and size of each object is printed on stdout. 31 |

32 |
33 |
34 |
35 |

OPTIONS

36 |
37 |
38 |
<object>
39 |

The name of the object to show. 40 | For a more complete list of ways to spell object names, see 41 | the "SPECIFYING REVISIONS" section in gitrevisions(7).

42 |
-t
43 |

Instead of the content, show the object type identified by 44 | <object>.

45 |
-s
46 |

Instead of the content, show the object size identified by 47 | <object>.

48 |
-e
49 |

Suppress all output; instead exit with zero status if <object> 50 | exists and is a valid object.

51 |
-p
52 |

Pretty-print the contents of <object> based on its type.

53 |
<type>
54 |

Typically this matches the real type of <object> but asking 55 | for a type that can trivially be dereferenced from the given 56 | <object> is also permitted. An example is to ask for a 57 | "tree" with <object> being a commit object that contains it, 58 | or to ask for a "blob" with <object> being a tag object that 59 | points at it.

60 |
--textconv
61 |

Show the content as transformed by a textconv filter. In this case, 62 | <object> has be of the form <tree-ish>:<path>, or :<path> in order 63 | to apply the filter to the content recorded in the index at <path>.

64 |
--batch
65 |
--batch=<format>
66 |

Print object information and contents for each object provided 67 | on stdin. May not be combined with any other options or arguments. 68 | See the section BATCH OUTPUT below for details.

69 |
--batch-check
70 |
--batch-check=<format>
71 |

Print object information for each object provided on stdin. May 72 | not be combined with any other options or arguments. See the 73 | section BATCH OUTPUT below for details.

74 |
75 |
76 |
77 |
78 |

OUTPUT

79 |
80 |

If -t is specified, one of the <type>. 81 |

82 |
83 |
84 |

If -s is specified, the size of the <object> in bytes. 85 |

86 |
87 |
88 |

If -e is specified, no output. 89 |

90 |
91 |
92 |

If -p is specified, the contents of <object> are pretty-printed. 93 |

94 |
95 |
96 |

If <type> is specified, the raw (though uncompressed) contents of the <object> 97 | will be returned. 98 |

99 |
100 |
101 |
102 |

BATCH OUTPUT

103 |
104 |

If --batch or --batch-check is given, cat-file will read objects 105 | from stdin, one per line, and print information about them. By default, 106 | the whole line is considered as an object, as if it were fed to 107 | git-rev-parse(1). 108 |

109 |
110 |
111 |

You can specify the information shown for each object by using a custom 112 | <format>. The <format> is copied literally to stdout for each 113 | object, with placeholders of the form %(atom) expanded, followed by a 114 | newline. The available atoms are: 115 |

116 |
117 |
118 |
119 |
objectname
120 |

The 40-hex object name of the object.

121 |
objecttype
122 |

The type of of the object (the same as cat-file -t reports).

123 |
objectsize
124 |

The size, in bytes, of the object (the same as cat-file -s 125 | reports).

126 |
objectsize:disk
127 |

The size, in bytes, that the object takes up on disk. See the 128 | note about on-disk sizes in the CAVEATS section below.

129 |
rest
130 |

If this atom is used in the output string, input lines are split 131 | at the first whitespace boundary. All characters before that 132 | whitespace are considered to be the object name; characters 133 | after that first run of whitespace (i.e., the "rest" of the 134 | line) are output in place of the %(rest) atom.

135 |
136 |
137 |
138 |

If no format is specified, the default format is %(objectname) 139 | %(objecttype) %(objectsize). 140 |

141 |
142 |
143 |

If --batch is specified, the object information is followed by the 144 | object contents (consisting of %(objectsize) bytes), followed by a 145 | newline. 146 |

147 |
148 |
149 |

For example, --batch without a custom format would produce: 150 |

151 |
152 |
153 |
154 | 
<sha1> SP <type> SP <size> LF
155 | <contents> LF
156 |
157 |
158 |
159 |
160 |

Whereas --batch-check='%(objectname) %(objecttype)' would produce: 161 |

162 |
163 |
164 |
165 | 
<sha1> SP <type> LF
166 |
167 |
168 |
169 |
170 |

If a name is specified on stdin that cannot be resolved to an object in 171 | the repository, then cat-file will ignore any custom format and print: 172 |

173 |
174 |
175 |
176 | 
<object> SP missing LF
177 |
178 |
179 |
180 |
181 |
182 |

CAVEATS

183 |
184 |

Note that the sizes of objects on disk are reported accurately, but care 185 | should be taken in drawing conclusions about which refs or objects are 186 | responsible for disk usage. The size of a packed non-delta object may be 187 | much larger than the size of objects which delta against it, but the 188 | choice of which object is the base and which is the delta is arbitrary 189 | and is subject to change during a repack. Note also that multiple copies 190 | of an object may be present in the object database; in this case, it is 191 | undefined which copy's size will be reported. 192 |

193 |
194 |
195 |
196 |

GIT

197 |
198 |

Part of the git(1) suite 199 |

200 |
201 |
202 |
203 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-cherry-pick.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
 16 | git cherry-pick --continue
 17 | git cherry-pick --quit
 18 | git cherry-pick --abort
19 |
20 |
21 |
22 |
23 |

DESCRIPTION

24 |
25 |

Given one or more existing commits, apply the change each one 26 | introduces, recording a new commit for each. This requires your 27 | working tree to be clean (no modifications from the HEAD commit). 28 |

29 |
30 |
31 |

When it is not obvious how to apply a change, the following 32 | happens: 33 |

34 |
35 |
36 |
    37 |

  1. The current branch and HEAD pointer stay at the last commit 38 | successfully made.

    2. 39 |

  2. The CHERRY_PICK_HEAD ref is set to point at the commit that 40 | introduced the change that is difficult to apply.

    3. 41 |

  3. Paths in which the change applied cleanly are updated both 42 | in the index file and in your working tree.

    4. 43 |

  4. For conflicting paths, the index file records up to three 44 | versions, as described in the "TRUE MERGE" section of 45 | git-merge(1). The working tree files will include 46 | a description of the conflict bracketed by the usual 47 | conflict markers <<<<<<< and >>>>>>>.

    5. 48 |

  5. No other modifications are made.

    6. 49 |
50 |
51 |
52 |

See git-merge(1) for some hints on resolving such 53 | conflicts. 54 |

55 |
56 |
57 |
58 |
59 |

OPTIONS

60 |
61 |
62 |
<commit>...
63 |

Commits to cherry-pick. 64 | For a more complete list of ways to spell commits, see 65 | gitrevisions(7). 66 | Sets of commits can be passed but no traversal is done by 67 | default, as if the --no-walk option was specified, see 68 | git-rev-list(1). Note that specifying a range will 69 | feed all <commit>... arguments to a single revision walk 70 | (see a later example that uses maint master..next).

71 |
-e
72 |
--edit
73 |

With this option, git cherry-pick will let you edit the commit 74 | message prior to committing.

75 |
-x
76 |

When recording the commit, append a line that says 77 | "(cherry picked from commit ...)" to the original commit 78 | message in order to indicate which commit this change was 79 | cherry-picked from. This is done only for cherry 80 | picks without conflicts. Do not use this option if 81 | you are cherry-picking from your private branch because 82 | the information is useless to the recipient. If on the 83 | other hand you are cherry-picking between two publicly 84 | visible branches (e.g. backporting a fix to a 85 | maintenance branch for an older release from a 86 | development branch), adding this information can be 87 | useful.

88 |
-r
89 |

It used to be that the command defaulted to do -x 90 | described above, and -r was to disable it. Now the 91 | default is not to do -x so this option is a no-op.

92 |
-m parent-number
93 |
--mainline parent-number
94 |

Usually you cannot cherry-pick a merge because you do not know which 95 | side of the merge should be considered the mainline. This 96 | option specifies the parent number (starting from 1) of 97 | the mainline and allows cherry-pick to replay the change 98 | relative to the specified parent.

99 |
-n
100 |
--no-commit
101 |

Usually the command automatically creates a sequence of commits. 102 | This flag applies the changes necessary to cherry-pick 103 | each named commit to your working tree and the index, 104 | without making any commit. In addition, when this 105 | option is used, your index does not have to match the 106 | HEAD commit. The cherry-pick is done against the 107 | beginning state of your index.

108 |

109 |
110 |
111 |

This is useful when cherry-picking more than one commits' 112 | effect to your index in a row. 113 |

114 |
115 |
116 |
-s
117 |
--signoff
118 |

Add Signed-off-by line at the end of the commit message.

119 |
--ff
120 |

If the current HEAD is the same as the parent of the 121 | cherry-pick'ed commit, then a fast forward to this commit will 122 | be performed.

123 |
--allow-empty
124 |

By default, cherry-picking an empty commit will fail, 125 | indicating that an explicit invocation of git commit 126 | --allow-empty is required. This option overrides that 127 | behavior, allowing empty commits to be preserved automatically 128 | in a cherry-pick. Note that when "--ff" is in effect, empty 129 | commits that meet the "fast-forward" requirement will be kept 130 | even without this option. Note also, that use of this option only 131 | keeps commits that were initially empty (i.e. the commit recorded the 132 | same tree as its parent). Commits which are made empty due to a 133 | previous commit are dropped. To force the inclusion of those commits 134 | use --keep-redundant-commits.

135 |
--allow-empty-message
136 |

By default, cherry-picking a commit with an empty message will fail. 137 | This option overrides that behaviour, allowing commits with empty 138 | messages to be cherry picked.

139 |
--keep-redundant-commits
140 |

If a commit being cherry picked duplicates a commit already in the 141 | current history, it will become empty. By default these 142 | redundant commits are ignored. This option overrides that behavior and 143 | creates an empty commit object. Implies --allow-empty.

144 |
--strategy=<strategy>
145 |

Use the given merge strategy. Should only be used once. 146 | See the MERGE STRATEGIES section in git-merge(1) 147 | for details.

148 |
-X<option>
149 |
--strategy-option=<option>
150 |

Pass the merge strategy-specific option through to the 151 | merge strategy. See git-merge(1) for details.

152 |
153 |
154 |
155 |
156 |
157 |

SEQUENCER SUBCOMMANDS

158 |
159 |
160 |
--continue
161 |

Continue the operation in progress using the information in 162 | .git/sequencer. Can be used to continue after resolving 163 | conflicts in a failed cherry-pick or revert.

164 |
--quit
165 |

Forget about the current operation in progress. Can be used 166 | to clear the sequencer state after a failed cherry-pick or 167 | revert.

168 |
--abort
169 |

Cancel the operation and return to the pre-sequence state.

170 |
171 |
172 |
173 |
174 |
175 |

EXAMPLES

176 |
177 |
178 |
git cherry-pick master
179 |

Apply the change introduced by the commit at the tip of the 180 | master branch and create a new commit with this change.

181 |
git cherry-pick ..master
182 |
git cherry-pick ^HEAD master
183 |

Apply the changes introduced by all commits that are ancestors 184 | of master but not of HEAD to produce new commits.

185 |
git cherry-pick maint next ^master
186 |
git cherry-pick maint master..next
187 |

Apply the changes introduced by all commits that are 188 | ancestors of maint or next, but not master or any of its 189 | ancestors. Note that the latter does not mean maint and 190 | everything between master and next; specifically, 191 | maint will not be used if it is included in master.

192 |
git cherry-pick master~4 master~2
193 |

Apply the changes introduced by the fifth and third last 194 | commits pointed to by master and create 2 new commits with 195 | these changes.

196 |
git cherry-pick -n master~1 next
197 |

Apply to the working tree and the index the changes introduced 198 | by the second last commit pointed to by master and by the last 199 | commit pointed to by next, but do not create any commit with 200 | these changes.

201 |
git cherry-pick --ff ..next
202 |

If history is linear and HEAD is an ancestor of next, update 203 | the working tree and advance the HEAD pointer to match next. 204 | Otherwise, apply the changes introduced by those commits that 205 | are in next but not HEAD to the current branch, creating a new 206 | commit for each new change.

207 |
git rev-list --reverse master -- README | git cherry-pick -n --stdin
208 |

Apply the changes introduced by all commits on the master 209 | branch that touched README to the working tree and index, 210 | so the result can be inspected and made into a single new 211 | commit if suitable.

212 |
213 |
214 |
215 |

The following sequence attempts to backport a patch, bails out because 216 | the code the patch applies to has changed too much, and then tries 217 | again, this time exercising more care about matching up context lines. 218 |

219 |
220 |
221 |
222 | 
$ git cherry-pick topic^             <1>
223 | $ git diff                           <2>
224 | $ git reset --merge ORIG_HEAD        <3>
225 | $ git cherry-pick -Xpatience topic^  <4>
226 |
227 |
228 |
229 |
230 |
    231 |

  1. apply the change that would be shown by git show topic^. 232 | In this example, the patch does not apply cleanly, so 233 | information about the conflict is written to the index and 234 | working tree and no new commit results.

    2. 235 |

  2. summarize changes to be reconciled

    3. 236 |

  3. cancel the cherry-pick. In other words, return to the 237 | pre-cherry-pick state, preserving any local modifications you had in 238 | the working tree.

    4. 239 |

  4. try to apply the change introduced by topic^ again, 240 | spending extra time to avoid mistakes based on incorrectly matching 241 | context lines.

    5. 242 |
243 |
244 |
245 |
246 |
247 |

SEE ALSO

248 |
249 |

git-revert(1) 250 |

251 |
252 |
253 |
254 |
255 |

GIT

256 |
257 |

Part of the git(1) suite 258 |

259 |
260 |
261 |
262 |
263 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-clean.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git clean [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>...
16 |
17 |
18 |
19 |

DESCRIPTION

20 |
21 |

Cleans the working tree by recursively removing files that are not 22 | under version control, starting from the current directory. 23 |

24 |
25 |
26 |

Normally, only files unknown to Git are removed, but if the -x 27 | option is specified, ignored files are also removed. This can, for 28 | example, be useful to remove all build products. 29 |

30 |
31 |
32 |

If any optional <path>... arguments are given, only those paths 33 | are affected. 34 |

35 |
36 |
37 |
38 |

OPTIONS

39 |
40 |
41 |
-d
42 |

Remove untracked directories in addition to untracked files. 43 | If an untracked directory is managed by a different Git 44 | repository, it is not removed by default. Use -f option twice 45 | if you really want to remove such a directory.

46 |
-f
47 |
--force
48 |

If the Git configuration variable clean.requireForce is not set 49 | to false, git clean will refuse to run unless given -f, -n or 50 | -i.

51 |
-i
52 |
--interactive
53 |

Show what would be done and clean files interactively. See 54 | “Interactive mode” for details.

55 |
-n
56 |
--dry-run
57 |

Don't actually remove anything, just show what would be done.

58 |
-q
59 |
--quiet
60 |

Be quiet, only report errors, but not the files that are 61 | successfully removed.

62 |
-e <pattern>
63 |
--exclude=<pattern>
64 |

In addition to those found in .gitignore (per directory) and 65 | $GIT_DIR/info/exclude, also consider these patterns to be in the 66 | set of the ignore rules in effect.

67 |
-x
68 |

Don't use the standard ignore rules read from .gitignore (per 69 | directory) and $GIT_DIR/info/exclude, but do still use the ignore 70 | rules given with -e options. This allows removing all untracked 71 | files, including build products. This can be used (possibly in 72 | conjunction with git reset) to create a pristine 73 | working directory to test a clean build.

74 |
-X
75 |

Remove only files ignored by Git. This may be useful to rebuild 76 | everything from scratch, but keep manually created files.

77 |
78 |
79 |
80 |
81 |

Interactive mode

82 |
83 |

When the command enters the interactive mode, it shows the 84 | files and directories to be cleaned, and goes into its 85 | interactive command loop. 86 |

87 |
88 |
89 |

The command loop shows the list of subcommands available, and 90 | gives a prompt "What now> ". In general, when the prompt ends 91 | with a single >, you can pick only one of the choices given 92 | and type return, like this: 93 |

94 |
95 |
96 |
97 | 
    *** Commands ***
 98 | 	1: clean                2: filter by pattern    3: select by numbers
 99 | 	4: ask each             5: quit                 6: help
100 |     What now> 1
101 |
102 |
103 |
104 |
105 |

You also could say c or clean above as long as the choice is unique. 106 |

107 |
108 |
109 |

The main command loop has 6 subcommands. 110 |

111 |
112 |
113 |
114 |
clean
115 |

Start cleaning files and directories, and then quit.

116 |
filter by pattern
117 |

This shows the files and directories to be deleted and issues an 118 | "Input ignore patterns>>" prompt. You can input space-seperated 119 | patterns to exclude files and directories from deletion. 120 | E.g. ".c .h" will excludes files end with ".c" and ".h" from 121 | deletion. When you are satisfied with the filtered result, press 122 | ENTER (empty) back to the main menu.

123 |
select by numbers
124 |

This shows the files and directories to be deleted and issues an 125 | "Select items to delete>>" prompt. When the prompt ends with double 126 | >> like this, you can make more than one selection, concatenated 127 | with whitespace or comma. Also you can say ranges. E.g. "2-5 7,9" 128 | to choose 2,3,4,5,7,9 from the list. If the second number in a 129 | range is omitted, all remaining items are selected. E.g. "7-" to 130 | choose 7,8,9 from the list. You can say * to choose everything. 131 | Also when you are satisfied with the filtered result, press ENTER 132 | (empty) back to the main menu.

133 |
ask each
134 |

This will start to clean, and you must confirm one by one in order 135 | to delete items. Please note that this action is not as efficient 136 | as the above two actions.

137 |
quit
138 |

This lets you quit without do cleaning.

139 |
help
140 |

Show brief usage of interactive git-clean.

141 |
142 |
143 |
144 |
145 |

SEE ALSO

146 |
147 |

gitignore(5) 148 |

149 |
150 |
151 |
152 |

GIT

153 |
154 |

Part of the git(1) suite 155 |

156 |
157 |
158 |
159 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-commit-tree.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git commit-tree <tree> [(-p <parent>)...] < changelog
 16 | git commit-tree [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...]
 17 | [(-F <file>)...] <tree>
18 |
19 |
20 |
21 |

DESCRIPTION

22 |
23 |

This is usually not what an end user wants to run directly. See 24 | git-commit(1) instead. 25 |

26 |
27 |
28 |

Creates a new commit object based on the provided tree object and 29 | emits the new commit object id on stdout. The log message is read 30 | from the standard input, unless -m or -F options are given. 31 |

32 |
33 |
34 |

A commit object may have any number of parents. With exactly one 35 | parent, it is an ordinary commit. Having more than one parent makes 36 | the commit a merge between several lines of history. Initial (root) 37 | commits have no parents. 38 |

39 |
40 |
41 |

While a tree represents a particular directory state of a working 42 | directory, a commit represents that state in "time", and explains how 43 | to get there. 44 |

45 |
46 |
47 |

Normally a commit would identify a new "HEAD" state, and while Git 48 | doesn't care where you save the note about that state, in practice we 49 | tend to just write the result to the file that is pointed at by 50 | .git/HEAD, so that we can always see what the last committed 51 | state was. 52 |

53 |
54 |
55 |
56 |

OPTIONS

57 |
58 |
59 |
<tree>
60 |

An existing tree object

61 |
-p <parent>
62 |

Each -p indicates the id of a parent commit object.

63 |
-m <message>
64 |

A paragraph in the commit log message. This can be given more than 65 | once and each <message> becomes its own paragraph.

66 |
-F <file>
67 |

Read the commit log message from the given file. Use - to read 68 | from the standard input.

69 |
-S[<keyid>]
70 |

GPG-sign commit.

71 |
72 |
73 |
74 |
75 |

Commit Information

76 |
77 |

A commit encapsulates: 78 |

79 |
80 |
81 |
    82 |

  • all parent object ids

    • 83 |

  • author name, email and date

    • 84 |

  • committer name and email and the commit time.

    • 85 |
86 |
87 |
88 |

While parent object ids are provided on the command line, author and 89 | committer information is taken from the following environment variables, 90 | if set: 91 |

92 |
93 |
94 |
95 | 
	GIT_AUTHOR_NAME
 96 | 	GIT_AUTHOR_EMAIL
 97 | 	GIT_AUTHOR_DATE
 98 | 	GIT_COMMITTER_NAME
 99 | 	GIT_COMMITTER_EMAIL
100 | 	GIT_COMMITTER_DATE
101 |
102 |
103 |
104 |
105 |

(nb "<", ">" and "\n"s are stripped) 106 |

107 |
108 |
109 |

In case (some of) these environment variables are not set, the information 110 | is taken from the configuration items user.name and user.email, or, if not 111 | present, the environment variable EMAIL, or, if that is not set, 112 | system user name and the hostname used for outgoing mail (taken 113 | from /etc/mailname and falling back to the fully qualified hostname when 114 | that file does not exist). 115 |

116 |
117 |
118 |

A commit comment is read from stdin. If a changelog 119 | entry is not provided via "<" redirection, git commit-tree will just wait 120 | for one to be entered and terminated with ^D. 121 |

122 |
123 |
124 |
125 |

DATE FORMATS

126 |
127 |

The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables 128 | support the following date formats: 129 |

130 |
131 |
132 |
133 |
Git internal format
134 |

It is <unix timestamp> <time zone offset>, where <unix 135 | timestamp> is the number of seconds since the UNIX epoch. 136 | <time zone offset> is a positive or negative offset from UTC. 137 | For example CET (which is 2 hours ahead UTC) is +0200.

138 |
RFC 2822
139 |

The standard email format as described by RFC 2822, for example 140 | Thu, 07 Apr 2005 22:13:13 +0200.

141 |
ISO 8601
142 |

Time and date specified by the ISO 8601 standard, for example 143 | 2005-04-07T22:13:13. The parser accepts a space instead of the 144 | T character as well.

145 |

146 |
147 |
148 | 149 | 150 | 151 | 154 | 155 |
Note
In addition, the date part is accepted in the following formats: 152 | YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY. 153 |
156 |
157 |
158 |
159 |
160 |
161 |
162 |

Discussion

163 |
164 |

At the core level, Git is character encoding agnostic. 165 |

166 |
167 |
168 |
    169 |

  • The pathnames recorded in the index and in the tree objects 170 | are treated as uninterpreted sequences of non-NUL bytes. 171 | What readdir(2) returns are what are recorded and compared 172 | with the data Git keeps track of, which in turn are expected 173 | to be what lstat(2) and creat(2) accepts. There is no such 174 | thing as pathname encoding translation.

    • 175 |

  • The contents of the blob objects are uninterpreted sequences 176 | of bytes. There is no encoding translation at the core 177 | level.

    • 178 |

  • The commit log messages are uninterpreted sequences of non-NUL 179 | bytes.

    • 180 |
181 |
182 |
183 |

Although we encourage that the commit log messages are encoded 184 | in UTF-8, both the core and Git Porcelain are designed not to 185 | force UTF-8 on projects. If all participants of a particular 186 | project find it more convenient to use legacy encodings, Git 187 | does not forbid it. However, there are a few things to keep in 188 | mind. 189 |

190 |
191 |
192 |
    193 |

  1. git commit and git commit-tree issues 194 | a warning if the commit log message given to it does not look 195 | like a valid UTF-8 string, unless you explicitly say your 196 | project uses a legacy encoding. The way to say this is to 197 | have i18n.commitencoding in .git/config file, like this:

    198 |
    199 | 
    [i18n]
200 | 	commitencoding = ISO-8859-1
201 |
    202 |
    203 |
    204 |
    205 |

    206 |
    207 |
    208 |

    Commit objects created with the above setting record the value 209 | of i18n.commitencoding in its encoding header. This is to 210 | help other people who look at them later. Lack of this header 211 | implies that the commit log message is encoded in UTF-8. 212 |

    213 |
    214 |
    2. 215 |

  2. git log, git show, git blame and friends look at the 216 | encoding header of a commit object, and try to re-code the 217 | log message into UTF-8 unless otherwise specified. You can 218 | specify the desired output encoding with 219 | i18n.logoutputencoding in .git/config file, like this:

    220 |
    221 | 
    [i18n]
222 | 	logoutputencoding = ISO-8859-1
223 |
    224 |
    225 |
    226 |
    227 |

    228 |
    229 |
    230 |

    If you do not have this configuration variable, the value of 231 | i18n.commitencoding is used instead. 232 |

    233 |
    234 |
    3. 235 |
236 |
237 |
238 |

Note that we deliberately chose not to re-code the commit log 239 | message when a commit is made to force UTF-8 at the commit 240 | object level, because re-coding to UTF-8 is not necessarily a 241 | reversible operation. 242 |

243 |
244 |
245 |
246 |

FILES

247 |
248 |

/etc/mailname 249 |

250 |
251 |
252 |
253 |

SEE ALSO

254 |
255 |

git-write-tree(1) 256 |

257 |
258 |
259 |
260 |

GIT

261 |
262 |

Part of the git(1) suite 263 |

264 |
265 |
266 |
267 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-count-objects.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git count-objects [-v] [-H | --human-readable]
16 |
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

This counts the number of unpacked object files and disk space consumed by 23 | them, to help you decide when it is a good time to repack. 24 |

25 |
26 |
27 |
28 |
29 |

OPTIONS

30 |
31 |
32 |
-v
33 |
--verbose
34 |

Report in more detail:

35 |

36 |
37 |
38 |

count: the number of loose objects 39 |

40 |
41 |
42 |

size: disk space consumed by loose objects, in KiB (unless -H is specified) 43 |

44 |
45 |
46 |

in-pack: the number of in-pack objects 47 |

48 |
49 |
50 |

size-pack: disk space consumed by the packs, in KiB (unless -H is specified) 51 |

52 |
53 |
54 |

prune-packable: the number of loose objects that are also present in 55 | the packs. These objects could be pruned using git prune-packed. 56 |

57 |
58 |
59 |

garbage: the number of files in object database that are not valid 60 | loose objects nor valid packs 61 |

62 |
63 |
64 |

size-garbage: disk space consumed by garbage files, in KiB (unless -H is 65 | specified) 66 |

67 |
68 |
69 |
-H
70 |
--human-readable
71 |

Print sizes in human readable format

72 |
73 |
74 |
75 |
76 |
77 |

GIT

78 |
79 |

Part of the git(1) suite 80 |

81 |
82 |
83 |
84 |
85 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-describe.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git describe [--all] [--tags] [--contains] [--abbrev=<n>] <commit-ish>...
 16 | git describe [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

The command finds the most recent tag that is reachable from a 23 | commit. If the tag points to the commit, then only the tag is 24 | shown. Otherwise, it suffixes the tag name with the number of 25 | additional commits on top of the tagged object and the 26 | abbreviated object name of the most recent commit. 27 |

28 |
29 |
30 |

By default (without --all or --tags) git describe only shows 31 | annotated tags. For more information about creating annotated tags 32 | see the -a and -s options to git-tag(1). 33 |

34 |
35 |
36 |
37 |

OPTIONS

38 |
39 |
40 |
<commit-ish>...
41 |

Commit-ish object names to describe.

42 |
--dirty[=<mark>]
43 |

Describe the working tree. 44 | It means describe HEAD and appends <mark> (-dirty by 45 | default) if the working tree is dirty.

46 |
--all
47 |

Instead of using only the annotated tags, use any ref 48 | found in refs/ namespace. This option enables matching 49 | any known branch, remote-tracking branch, or lightweight tag.

50 |
--tags
51 |

Instead of using only the annotated tags, use any tag 52 | found in refs/tags namespace. This option enables matching 53 | a lightweight (non-annotated) tag.

54 |
--contains
55 |

Instead of finding the tag that predates the commit, find 56 | the tag that comes after the commit, and thus contains it. 57 | Automatically implies --tags.

58 |
--abbrev=<n>
59 |

Instead of using the default 7 hexadecimal digits as the 60 | abbreviated object name, use <n> digits, or as many digits 61 | as needed to form a unique object name. An <n> of 0 62 | will suppress long format, only showing the closest tag.

63 |
--candidates=<n>
64 |

Instead of considering only the 10 most recent tags as 65 | candidates to describe the input commit-ish consider 66 | up to <n> candidates. Increasing <n> above 10 will take 67 | slightly longer but may produce a more accurate result. 68 | An <n> of 0 will cause only exact matches to be output.

69 |
--exact-match
70 |

Only output exact matches (a tag directly references the 71 | supplied commit). This is a synonym for --candidates=0.

72 |
--debug
73 |

Verbosely display information about the searching strategy 74 | being employed to standard error. The tag name will still 75 | be printed to standard out.

76 |
--long
77 |

Always output the long format (the tag, the number of commits 78 | and the abbreviated commit name) even when it matches a tag. 79 | This is useful when you want to see parts of the commit object name 80 | in "describe" output, even when the commit in question happens to be 81 | a tagged version. Instead of just emitting the tag name, it will 82 | describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2 83 | that points at object deadbee....).

84 |
--match <pattern>
85 |

Only consider tags matching the given glob(7) pattern, 86 | excluding the "refs/tags/" prefix. This can be used to avoid 87 | leaking private tags from the repository.

88 |
--always
89 |

Show uniquely abbreviated commit object as fallback.

90 |
--first-parent
91 |

Follow only the first parent commit upon seeing a merge commit. 92 | This is useful when you wish to not match tags on branches merged 93 | in the history of the target commit.

94 |
95 |
96 |
97 |
98 |

EXAMPLES

99 |
100 |

With something like git.git current tree, I get: 101 |

102 |
103 |
104 |
105 | 
	[torvalds@g5 git]$ git describe parent
106 | 	v1.0.4-14-g2414721
107 |
108 |
109 |
110 |
111 |

i.e. the current head of my "parent" branch is based on v1.0.4, 112 | but since it has a few commits on top of that, 113 | describe has added the number of additional commits ("14") and 114 | an abbreviated object name for the commit itself ("2414721") 115 | at the end. 116 |

117 |
118 |
119 |

The number of additional commits is the number 120 | of commits which would be displayed by "git log v1.0.4..parent". 121 | The hash suffix is "-g" + 7-char abbreviation for the tip commit 122 | of parent (which was 2414721b194453f058079d897d13c4e377f92dc6). 123 | The "g" prefix stands for "git" and is used to allow describing the version of 124 | a software depending on the SCM the software is managed with. This is useful 125 | in an environment where people may use different SCMs. 126 |

127 |
128 |
129 |

Doing a git describe on a tag-name will just show the tag name: 130 |

131 |
132 |
133 |
134 | 
	[torvalds@g5 git]$ git describe v1.0.4
135 | 	v1.0.4
136 |
137 |
138 |
139 |
140 |

With --all, the command can use branch heads as references, so 141 | the output shows the reference path as well: 142 |

143 |
144 |
145 |
146 | 
	[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
147 | 	tags/v1.0.0-21-g975b
148 |
149 |
150 |
151 |
152 |
153 | 
	[torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^
154 | 	heads/lt/describe-7-g975b
155 |
156 |
157 |
158 |
159 |

With --abbrev set to 0, the command can be used to find the 160 | closest tagname without any suffix: 161 |

162 |
163 |
164 |
165 | 
	[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
166 | 	tags/v1.0.0
167 |
168 |
169 |
170 |
171 |

Note that the suffix you get if you type these commands today may be 172 | longer than what Linus saw above when he ran these commands, as your 173 | Git repository may have new commits whose object names begin with 174 | 975b that did not exist back then, and "-g975b" suffix alone may not 175 | be sufficient to disambiguate these commits. 176 |

177 |
178 |
179 |
180 |

SEARCH STRATEGY

181 |
182 |

For each commit-ish supplied, git describe will first look for 183 | a tag which tags exactly that commit. Annotated tags will always 184 | be preferred over lightweight tags, and tags with newer dates will 185 | always be preferred over tags with older dates. If an exact match 186 | is found, its name will be output and searching will stop. 187 |

188 |
189 |
190 |

If an exact match was not found, git describe will walk back 191 | through the commit history to locate an ancestor commit which 192 | has been tagged. The ancestor's tag will be output along with an 193 | abbreviation of the input commit-ish's SHA-1. If --first-parent was 194 | specified then the walk will only consider the first parent of each 195 | commit. 196 |

197 |
198 |
199 |

If multiple tags were found during the walk then the tag which 200 | has the fewest commits different from the input commit-ish will be 201 | selected and output. Here fewest commits different is defined as 202 | the number of commits which would be shown by git log tag..input 203 | will be the smallest number of commits possible. 204 |

205 |
206 |
207 |
208 |

GIT

209 |
210 |

Part of the git(1) suite 211 |

212 |
213 |
214 |
215 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-fsck.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
 16 | [--[no-]full] [--strict] [--verbose] [--lost-found]
 17 | [--[no-]dangling] [--[no-]progress] [<object>*]
18 |
19 |
20 |
21 |
22 |

DESCRIPTION

23 |
24 |

Verifies the connectivity and validity of the objects in the database. 25 |

26 |
27 |
28 |
29 |
30 |

OPTIONS

31 |
32 |
33 |
<object>
34 |

An object to treat as the head of an unreachability trace.

35 |

36 |
37 |
38 |

If no objects are given, git fsck defaults to using the 39 | index file, all SHA-1 references in refs namespace, and all reflogs 40 | (unless --no-reflogs is given) as heads. 41 |

42 |
43 |
44 |
--unreachable
45 |

Print out objects that exist but that aren't reachable from any 46 | of the reference nodes.

47 |
--[no-]dangling
48 |

Print objects that exist but that are never directly used (default). 49 | --no-dangling can be used to omit this information from the output.

50 |
--root
51 |

Report root nodes.

52 |
--tags
53 |

Report tags.

54 |
--cache
55 |

Consider any object recorded in the index also as a head node for 56 | an unreachability trace.

57 |
--no-reflogs
58 |

Do not consider commits that are referenced only by an 59 | entry in a reflog to be reachable. This option is meant 60 | only to search for commits that used to be in a ref, but 61 | now aren't, but are still in that corresponding reflog.

62 |
--full
63 |

Check not just objects in GIT_OBJECT_DIRECTORY 64 | ($GIT_DIR/objects), but also the ones found in alternate 65 | object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES 66 | or $GIT_DIR/objects/info/alternates, 67 | and in packed Git archives found in $GIT_DIR/objects/pack 68 | and corresponding pack subdirectories in alternate 69 | object pools. This is now default; you can turn it off 70 | with --no-full.

71 |
--strict
72 |

Enable more strict checking, namely to catch a file mode 73 | recorded with g+w bit set, which was created by older 74 | versions of Git. Existing repositories, including the 75 | Linux kernel, Git itself, and sparse repository have old 76 | objects that triggers this check, but it is recommended 77 | to check new projects with this flag.

78 |
--verbose
79 |

Be chatty.

80 |
--lost-found
81 |

Write dangling objects into .git/lost-found/commit/ or 82 | .git/lost-found/other/, depending on type. If the object is 83 | a blob, the contents are written into the file, rather than 84 | its object name.

85 |
--[no-]progress
86 |

Progress status is reported on the standard error stream by 87 | default when it is attached to a terminal, unless 88 | --no-progress or --verbose is specified. --progress forces 89 | progress status even if the standard error stream is not 90 | directed to a terminal.

91 |
92 |
93 |
94 |
95 |
96 |

DISCUSSION

97 |
98 |

git-fsck tests SHA-1 and general object sanity, and it does full tracking 99 | of the resulting reachability and everything else. It prints out any 100 | corruption it finds (missing or bad objects), and if you use the 101 | --unreachable flag it will also print out objects that exist but that 102 | aren't reachable from any of the specified head nodes (or the default 103 | set, as mentioned above). 104 |

105 |
106 |
107 |

Any corrupt objects you will have to find in backups or other archives 108 | (i.e., you can just remove them and do an rsync with some other site in 109 | the hopes that somebody else has the object you have corrupted). 110 |

111 |
112 |
113 |
114 |
115 |

Extracted Diagnostics

116 |
117 |
118 |
expect dangling commits - potential heads - due to lack of head information
119 |

You haven't specified any nodes as heads so it won't be 120 | possible to differentiate between un-parented commits and 121 | root nodes.

122 |
missing sha1 directory <dir>
123 |

The directory holding the sha1 objects is missing.

124 |
unreachable <type> <object>
125 |

The <type> object <object>, isn't actually referred to directly 126 | or indirectly in any of the trees or commits seen. This can 127 | mean that there's another root node that you're not specifying 128 | or that the tree is corrupt. If you haven't missed a root node 129 | then you might as well delete unreachable nodes since they 130 | can't be used.

131 |
missing <type> <object>
132 |

The <type> object <object>, is referred to but isn't present in 133 | the database.

134 |
dangling <type> <object>
135 |

The <type> object <object>, is present in the database but never 136 | directly used. A dangling commit could be a root node.

137 |
sha1 mismatch <object>
138 |

The database has an object who's sha1 doesn't match the 139 | database value. 140 | This indicates a serious data integrity problem.

141 |
142 |
143 |
144 |
145 |
146 |

Environment Variables

147 |
148 |
149 |
GIT_OBJECT_DIRECTORY
150 |

used to specify the object database root (usually $GIT_DIR/objects)

151 |
GIT_INDEX_FILE
152 |

used to specify the index file of the index

153 |
GIT_ALTERNATE_OBJECT_DIRECTORIES
154 |

used to specify additional object database roots (usually unset)

155 |
156 |
157 |
158 |
159 |
160 |

GIT

161 |
162 |

Part of the git(1) suite 163 |

164 |
165 |
166 |
167 |
168 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-gc.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git gc [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force]
16 |
17 |
18 |
19 |

DESCRIPTION

20 |
21 |

Runs a number of housekeeping tasks within the current repository, 22 | such as compressing file revisions (to reduce disk space and increase 23 | performance) and removing unreachable objects which may have been 24 | created from prior invocations of git add. 25 |

26 |
27 |
28 |

Users are encouraged to run this task on a regular basis within 29 | each repository to maintain good disk space utilization and good 30 | operating performance. 31 |

32 |
33 |
34 |

Some git commands may automatically run git gc; see the --auto flag 35 | below for details. If you know what you're doing and all you want is to 36 | disable this behavior permanently without further considerations, just do: 37 |

38 |
39 |
40 |
41 | 
$ git config --global gc.auto 0
 42 |
43 |
44 |
45 |
46 |
47 |

OPTIONS

48 |
49 |
50 |
--aggressive
51 |

Usually git gc runs very quickly while providing good disk 52 | space utilization and performance. This option will cause 53 | git gc to more aggressively optimize the repository at the expense 54 | of taking much more time. The effects of this optimization are 55 | persistent, so this option only needs to be used occasionally; every 56 | few hundred changesets or so.

57 |
--auto
58 |

With this option, git gc checks whether any housekeeping is 59 | required; if not, it exits without performing any work. 60 | Some git commands run git gc --auto after performing 61 | operations that could create many loose objects.

62 |

63 |
64 |
65 |

Housekeeping is required if there are too many loose objects or 66 | too many packs in the repository. If the number of loose objects 67 | exceeds the value of the gc.auto configuration variable, then 68 | all loose objects are combined into a single pack using 69 | git repack -d -l. Setting the value of gc.auto to 0 70 | disables automatic packing of loose objects. 71 |

72 |
73 |
74 |

If the number of packs exceeds the value of gc.autopacklimit, 75 | then existing packs (except those marked with a .keep file) 76 | are consolidated into a single pack by using the -A option of 77 | git repack. Setting gc.autopacklimit to 0 disables 78 | automatic consolidation of packs. 79 |

80 |
81 |
82 |
--prune=<date>
83 |

Prune loose objects older than date (default is 2 weeks ago, 84 | overridable by the config variable gc.pruneExpire). 85 | --prune=all prunes loose objects regardless of their age. 86 | --prune is on by default.

87 |
--no-prune
88 |

Do not prune any loose objects.

89 |
--quiet
90 |

Suppress all progress reports.

91 |
--force
92 |

Force git gc to run even if there may be another git gc 93 | instance running on this repository.

94 |
95 |
96 |
97 |
98 |

Configuration

99 |
100 |

The optional configuration variable gc.reflogExpire can be 101 | set to indicate how long historical entries within each branch's 102 | reflog should remain available in this repository. The setting is 103 | expressed as a length of time, for example 90 days or 3 months. 104 | It defaults to 90 days. 105 |

106 |
107 |
108 |

The optional configuration variable gc.reflogExpireUnreachable 109 | can be set to indicate how long historical reflog entries which 110 | are not part of the current branch should remain available in 111 | this repository. These types of entries are generally created as 112 | a result of using git commit --amend or git rebase and are the 113 | commits prior to the amend or rebase occurring. Since these changes 114 | are not part of the current project most users will want to expire 115 | them sooner. This option defaults to 30 days. 116 |

117 |
118 |
119 |

The above two configuration variables can be given to a pattern. For 120 | example, this sets non-default expiry values only to remote-tracking 121 | branches: 122 |

123 |
124 |
125 |
126 | 
[gc "refs/remotes/*"]
127 | 	reflogExpire = never
128 | 	reflogexpireUnreachable = 3 days
129 |
130 |
131 |
132 |
133 |

The optional configuration variable gc.rerereresolved indicates 134 | how long records of conflicted merge you resolved earlier are 135 | kept. This defaults to 60 days. 136 |

137 |
138 |
139 |

The optional configuration variable gc.rerereunresolved indicates 140 | how long records of conflicted merge you have not resolved are 141 | kept. This defaults to 15 days. 142 |

143 |
144 |
145 |

The optional configuration variable gc.packrefs determines if 146 | git gc runs git pack-refs. This can be set to "notbare" to enable 147 | it within all non-bare repos or it can be set to a boolean value. 148 | This defaults to true. 149 |

150 |
151 |
152 |

The optional configuration variable gc.aggressiveWindow controls how 153 | much time is spent optimizing the delta compression of the objects in 154 | the repository when the --aggressive option is specified. The larger 155 | the value, the more time is spent optimizing the delta compression. See 156 | the documentation for the --window' option in git-repack(1) for 157 | more details. This defaults to 250. 158 |

159 |
160 |
161 |

The optional configuration variable gc.pruneExpire controls how old 162 | the unreferenced loose objects have to be before they are pruned. The 163 | default is "2 weeks ago". 164 |

165 |
166 |
167 |
168 |

Notes

169 |
170 |

git gc tries very hard to be safe about the garbage it collects. In 171 | particular, it will keep not only objects referenced by your current set 172 | of branches and tags, but also objects referenced by the index, 173 | remote-tracking branches, refs saved by git filter-branch in 174 | refs/original/, or reflogs (which may reference commits in branches 175 | that were later amended or rewound). 176 |

177 |
178 |
179 |

If you are expecting some objects to be collected and they aren't, check 180 | all of those locations and decide whether it makes sense in your case to 181 | remove those references. 182 |

183 |
184 |
185 |
186 |

HOOKS

187 |
188 |

The git gc --auto command will run the pre-auto-gc hook. See 189 | githooks(5) for more information. 190 |

191 |
192 |
193 |
194 |

SEE ALSO

195 |
196 |

git-prune(1) 197 | git-reflog(1) 198 | git-repack(1) 199 | git-rerere(1) 200 |

201 |
202 |
203 |
204 |

GIT

205 |
206 |

Part of the git(1) suite 207 |

208 |
209 |
210 |
211 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-grep.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git grep [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
 16 | [-v | --invert-match] [-h|-H] [--full-name]
 17 | [-E | --extended-regexp] [-G | --basic-regexp]
 18 | [-P | --perl-regexp]
 19 | [-F | --fixed-strings] [-n | --line-number]
 20 | [-l | --files-with-matches] [-L | --files-without-match]
 21 | [(-O | --open-files-in-pager) [<pager>]]
 22 | [-z | --null]
 23 | [-c | --count] [--all-match] [-q | --quiet]
 24 | [--max-depth <depth>]
 25 | [--color[=<when>] | --no-color]
 26 | [--break] [--heading] [-p | --show-function]
 27 | [-A <post-context>] [-B <pre-context>] [-C <context>]
 28 | [-W | --function-context]
 29 | [-f <file>] [-e] <pattern>
 30 | [--and|--or|--not|(|)|-e <pattern>...]
 31 | [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | <tree>...]
 32 | [--] [<pathspec>...]
33 |
34 |
35 |
36 |

DESCRIPTION

37 |
38 |

Look for specified patterns in the tracked files in the work tree, blobs 39 | registered in the index file, or blobs in given tree objects. Patterns 40 | are lists of one or more search expressions separated by newline 41 | characters. An empty string as search expression matches all lines. 42 |

43 |
44 |
45 |
46 |

CONFIGURATION

47 |
48 |
49 |
grep.lineNumber
50 |

If set to true, enable -n option by default.

51 |
grep.patternType
52 |

Set the default matching behavior. Using a value of basic, extended, 53 | fixed, or perl will enable the --basic-regexp, --extended-regexp, 54 | --fixed-strings, or --perl-regexp option accordingly, while the 55 | value default will return to the default matching behavior.

56 |
grep.extendedRegexp
57 |

If set to true, enable --extended-regexp option by default. This 58 | option is ignored when the grep.patternType option is set to a value 59 | other than default.

60 |
61 |
62 |
63 |
64 |

OPTIONS

65 |
66 |
67 |
--cached
68 |

Instead of searching tracked files in the working tree, search 69 | blobs registered in the index file.

70 |
--no-index
71 |

Search files in the current directory that is not managed by Git.

72 |
--untracked
73 |

In addition to searching in the tracked files in the working 74 | tree, search also in untracked files.

75 |
--no-exclude-standard
76 |

Also search in ignored files by not honoring the .gitignore 77 | mechanism. Only useful with --untracked.

78 |
--exclude-standard
79 |

Do not pay attention to ignored files specified via the .gitignore 80 | mechanism. Only useful when searching files in the current directory 81 | with --no-index.

82 |
-a
83 |
--text
84 |

Process binary files as if they were text.

85 |
--textconv
86 |

Honor textconv filter settings.

87 |
--no-textconv
88 |

Do not honor textconv filter settings. 89 | This is the default.

90 |
-i
91 |
--ignore-case
92 |

Ignore case differences between the patterns and the 93 | files.

94 |
-I
95 |

Don't match the pattern in binary files.

96 |
--max-depth <depth>
97 |

For each <pathspec> given on command line, descend at most <depth> 98 | levels of directories. A negative value means no limit. 99 | This option is ignored if <pathspec> contains active wildcards. 100 | In other words if "a" matches a directory named "a", 101 | "*" is matched literally so --max-depth is still effective.

102 |
-w
103 |
--word-regexp
104 |

Match the pattern only at word boundary (either begin at the 105 | beginning of a line, or preceded by a non-word character; end at 106 | the end of a line or followed by a non-word character).

107 |
-v
108 |
--invert-match
109 |

Select non-matching lines.

110 |
-h
111 |
-H
112 |

By default, the command shows the filename for each 113 | match. -h option is used to suppress this output. 114 | -H is there for completeness and does not do anything 115 | except it overrides -h given earlier on the command 116 | line.

117 |
--full-name
118 |

When run from a subdirectory, the command usually 119 | outputs paths relative to the current directory. This 120 | option forces paths to be output relative to the project 121 | top directory.

122 |
-E
123 |
--extended-regexp
124 |
-G
125 |
--basic-regexp
126 |

Use POSIX extended/basic regexp for patterns. Default 127 | is to use basic regexp.

128 |
-P
129 |
--perl-regexp
130 |

Use Perl-compatible regexp for patterns. Requires libpcre to be 131 | compiled in.

132 |
-F
133 |
--fixed-strings
134 |

Use fixed strings for patterns (don't interpret pattern 135 | as a regex).

136 |
-n
137 |
--line-number
138 |

Prefix the line number to matching lines.

139 |
-l
140 |
--files-with-matches
141 |
--name-only
142 |
-L
143 |
--files-without-match
144 |

Instead of showing every matched line, show only the 145 | names of files that contain (or do not contain) matches. 146 | For better compatibility with git diff, --name-only is a 147 | synonym for --files-with-matches.

148 |
-O [<pager>]
149 |
--open-files-in-pager [<pager>]
150 |

Open the matching files in the pager (not the output of grep). 151 | If the pager happens to be "less" or "vi", and the user 152 | specified only one pattern, the first file is positioned at 153 | the first match automatically.

154 |
-z
155 |
--null
156 |

Output \0 instead of the character that normally follows a 157 | file name.

158 |
-c
159 |
--count
160 |

Instead of showing every matched line, show the number of 161 | lines that match.

162 |
--color[=<when>]
163 |

Show colored matches. 164 | The value must be always (the default), never, or auto.

165 |
--no-color
166 |

Turn off match highlighting, even when the configuration file 167 | gives the default to color output. 168 | Same as --color=never.

169 |
--break
170 |

Print an empty line between matches from different files.

171 |
--heading
172 |

Show the filename above the matches in that file instead of 173 | at the start of each shown line.

174 |
-p
175 |
--show-function
176 |

Show the preceding line that contains the function name of 177 | the match, unless the matching line is a function name itself. 178 | The name is determined in the same way as git diff works out 179 | patch hunk headers (see Defining a custom hunk-header in 180 | gitattributes(5)).

181 |
-<num>
182 |
-C <num>
183 |
--context <num>
184 |

Show <num> leading and trailing lines, and place a line 185 | containing -- between contiguous groups of matches.

186 |
-A <num>
187 |
--after-context <num>
188 |

Show <num> trailing lines, and place a line containing 189 | -- between contiguous groups of matches.

190 |
-B <num>
191 |
--before-context <num>
192 |

Show <num> leading lines, and place a line containing 193 | -- between contiguous groups of matches.

194 |
-W
195 |
--function-context
196 |

Show the surrounding text from the previous line containing a 197 | function name up to the one before the next function name, 198 | effectively showing the whole function in which the match was 199 | found.

200 |
-f <file>
201 |

Read patterns from <file>, one per line.

202 |
-e
203 |

The next parameter is the pattern. This option has to be 204 | used for patterns starting with - and should be used in 205 | scripts passing user input to grep. Multiple patterns are 206 | combined by or.

207 |
--and
208 |
--or
209 |
--not
210 |
( ... )
211 |

Specify how multiple patterns are combined using Boolean 212 | expressions. --or is the default operator. --and has 213 | higher precedence than --or. -e has to be used for all 214 | patterns.

215 |
--all-match
216 |

When giving multiple pattern expressions combined with --or, 217 | this flag is specified to limit the match to files that 218 | have lines to match all of them.

219 |
-q
220 |
--quiet
221 |

Do not output matched lines; instead, exit with status 0 when 222 | there is a match and with non-zero status when there isn't.

223 |
<tree>...
224 |

Instead of searching tracked files in the working tree, search 225 | blobs in the given trees.

226 |
--
227 |

Signals the end of options; the rest of the parameters 228 | are <pathspec> limiters.

229 |
<pathspec>...
230 |

If given, limit the search to paths matching at least one pattern. 231 | Both leading paths match and glob(7) patterns are supported.

232 |
233 |
234 |
235 |
236 |

Examples

237 |
238 |
239 |
git grep 'time_t' -- '*.[ch]'
240 |

Looks for time_t in all tracked .c and .h files in the working 241 | directory and its subdirectories.

242 |
git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)
243 |

Looks for a line that has #define and either MAX_PATH or 244 | PATH_MAX.

245 |
git grep --all-match -e NODE -e Unexpected
246 |

Looks for a line that has NODE or Unexpected in 247 | files that have lines that match both.

248 |
249 |
250 |
251 |
252 |

GIT

253 |
254 |

Part of the git(1) suite 255 |

256 |
257 |
258 |
259 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-hash-object.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git hash-object [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin] [--] <file>...
16 | git hash-object [-t <type>] [-w] --stdin-paths [--no-filters] < <list-of-paths>
17 |
18 |
19 |
20 |
21 |

DESCRIPTION

22 |
23 |

Computes the object ID value for an object with specified type 24 | with the contents of the named file (which can be outside of the 25 | work tree), and optionally writes the resulting object into the 26 | object database. Reports its object ID to its standard output. 27 | This is used by git cvsimport to update the index 28 | without modifying files in the work tree. When <type> is not 29 | specified, it defaults to "blob". 30 |

31 |
32 |
33 |
34 |
35 |

OPTIONS

36 |
37 |
38 |
-t <type>
39 |

Specify the type (default: "blob").

40 |
-w
41 |

Actually write the object into the object database.

42 |
--stdin
43 |

Read the object from standard input instead of from a file.

44 |
--stdin-paths
45 |

Read file names from stdin instead of from the command-line.

46 |
--path
47 |

Hash object as it were located at the given path. The location of 48 | file does not directly influence on the hash value, but path is 49 | used to determine what Git filters should be applied to the object 50 | before it can be placed to the object database, and, as result of 51 | applying filters, the actual blob put into the object database may 52 | differ from the given file. This option is mainly useful for hashing 53 | temporary files located outside of the working directory or files 54 | read from stdin.

55 |
--no-filters
56 |

Hash the contents as is, ignoring any input filter that would 57 | have been chosen by the attributes mechanism, including the end-of-line 58 | conversion. If the file is read from standard input then this 59 | is always implied, unless the --path option is given.

60 |
61 |
62 |
63 |
64 |
65 |

GIT

66 |
67 |

Part of the git(1) suite 68 |

69 |
70 |
71 |
72 |
73 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-help.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git help [-a|--all] [-g|--guide]
 16 | [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
17 |
18 |
19 |
20 |
21 |

DESCRIPTION

22 |
23 |

With no options and no COMMAND or GUIDE given, the synopsis of the git 24 | command and a list of the most commonly used Git commands are printed 25 | on the standard output. 26 |

27 |
28 |
29 |

If the option --all or -a is given, all available commands are 30 | printed on the standard output. 31 |

32 |
33 |
34 |

If the option --guide or -g is given, a list of the useful 35 | Git guides is also printed on the standard output. 36 |

37 |
38 |
39 |

If a command, or a guide, is given, a manual page for that command or 40 | guide is brought up. The man program is used by default for this 41 | purpose, but this can be overridden by other options or configuration 42 | variables. 43 |

44 |
45 |
46 |

Note that git --help ... is identical to git help ... because the 47 | former is internally converted into the latter. 48 |

49 |
50 |
51 |

To display the git(1) man page, use git help git. 52 |

53 |
54 |
55 |

This page can be displayed with git help help or git help --help 56 |

57 |
58 |
59 |
60 |
61 |

OPTIONS

62 |
63 |
64 |
-a
65 |
--all
66 |

Prints all the available commands on the standard output. This 67 | option overrides any given command or guide name.

68 |
-g
69 |
--guides
70 |

Prints a list of useful guides on the standard output. This 71 | option overrides any given command or guide name.

72 |
-i
73 |
--info
74 |

Display manual page for the command in the info format. The 75 | info program will be used for that purpose.

76 |
-m
77 |
--man
78 |

Display manual page for the command in the man format. This 79 | option may be used to override a value set in the 80 | help.format configuration variable.

81 |

82 |
83 |
84 |

By default the man program will be used to display the manual page, 85 | but the man.viewer configuration variable may be used to choose 86 | other display programs (see below). 87 |

88 |
89 |
90 |
-w
91 |
--web
92 |

Display manual page for the command in the web (HTML) 93 | format. A web browser will be used for that purpose.

94 |

95 |
96 |
97 |

The web browser can be specified using the configuration variable 98 | help.browser, or web.browser if the former is not set. If none of 99 | these config variables is set, the git web--browse helper script 100 | (called by git help) will pick a suitable default. See 101 | git-web--browse(1) for more information about this. 102 |

103 |
104 |
105 |
106 |
107 |
108 |
109 |
110 |

CONFIGURATION VARIABLES

111 |
112 |

help.format

113 |
114 |

If no command line option is passed, the help.format configuration 115 | variable will be checked. The following values are supported for this 116 | variable; they make git help behave as their corresponding command 117 | line option: 118 |

119 |
120 |
121 |
    122 |

  • "man" corresponds to -m|--man,

    • 123 |

  • "info" corresponds to -i|--info,

    • 124 |

  • "web" or "html" correspond to -w|--web.

    • 125 |
126 |
127 |
128 |
129 |

help.browser, web.browser and browser..path

130 |
131 |

The help.browser, web.browser and browser.<tool>.path will also 132 | be checked if the web format is chosen (either by command line 133 | option or configuration variable). See -w|--web in the OPTIONS 134 | section above and git-web--browse(1). 135 |

136 |
137 |
138 |
139 |

man.viewer

140 |
141 |

The man.viewer config variable will be checked if the man format 142 | is chosen. The following values are currently supported: 143 |

144 |
145 |
146 |
    147 |

  • "man": use the man program as usual,

    • 148 |

  • "woman": use emacsclient to launch the "woman" mode in emacs 149 | (this only works starting with emacsclient versions 22),

    • 150 |

  • "konqueror": use kfmclient to open the man page in a new konqueror 151 | tab (see Note about konqueror below).

    • 152 |
153 |
154 |
155 |

Values for other tools can be used if there is a corresponding 156 | man.<tool>.cmd configuration entry (see below). 157 |

158 |
159 |
160 |

Multiple values may be given to the man.viewer configuration 161 | variable. Their corresponding programs will be tried in the order 162 | listed in the configuration file. 163 |

164 |
165 |
166 |

For example, this configuration: 167 |

168 |
169 |
170 |
171 | 
	[man]
172 | 		viewer = konqueror
173 | 		viewer = woman
174 |
175 |
176 |
177 |
178 |

will try to use konqueror first. But this may fail (for example if 179 | DISPLAY is not set) and in that case emacs' woman mode will be tried. 180 |

181 |
182 |
183 |

If everything fails, or if no viewer is configured, the viewer specified 184 | in the GIT_MAN_VIEWER environment variable will be tried. If that 185 | fails too, the man program will be tried anyway. 186 |

187 |
188 |
189 |
190 |

man..path

191 |
192 |

You can explicitly provide a full path to your preferred man viewer by 193 | setting the configuration variable man.<tool>.path. For example, you 194 | can configure the absolute path to konqueror by setting 195 | man.konqueror.path. Otherwise, git help assumes the tool is 196 | available in PATH. 197 |

198 |
199 |
200 |
201 |

man..cmd

202 |
203 |

When the man viewer, specified by the man.viewer configuration 204 | variables, is not among the supported ones, then the corresponding 205 | man.<tool>.cmd configuration variable will be looked up. If this 206 | variable exists then the specified tool will be treated as a custom 207 | command and a shell eval will be used to run the command with the man 208 | page passed as arguments. 209 |

210 |
211 |
212 |
213 |

Note about konqueror

214 |
215 |

When konqueror is specified in the man.viewer configuration 216 | variable, we launch kfmclient to try to open the man page on an 217 | already opened konqueror in a new tab if possible. 218 |

219 |
220 |
221 |

For consistency, we also try such a trick if man.konqueror.path is 222 | set to something like A_PATH_TO/konqueror. That means we will try to 223 | launch A_PATH_TO/kfmclient instead. 224 |

225 |
226 |
227 |

If you really want to use konqueror, then you can use something like 228 | the following: 229 |

230 |
231 |
232 |
233 | 
	[man]
234 | 		viewer = konq
235 | 
236 | 	[man "konq"]
237 | 		cmd = A_PATH_TO/konqueror
238 |
239 |
240 |
241 |
242 |
243 |

Note about git config --global

244 |
245 |

Note that all these configuration variables should probably be set 246 | using the --global flag, for example like this: 247 |

248 |
249 |
250 |
251 | 
$ git config --global help.format web
252 | $ git config --global web.browser firefox
253 |
254 |
255 |
256 |
257 |

as they are probably more user specific than repository specific. 258 | See git-config(1) for more information about this. 259 |

260 |
261 |
262 |
263 |
264 |
265 |

GIT

266 |
267 |

Part of the git(1) suite 268 |

269 |
270 |
271 |
272 |
273 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-init.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git init [-q | --quiet] [--bare] [--template=<template_directory>]
 16 | [--separate-git-dir <git dir>]
 17 | [--shared[=<permissions>]] [directory]
18 |
19 |
20 |
21 |
22 |

DESCRIPTION

23 |
24 |

This command creates an empty Git repository - basically a .git 25 | directory with subdirectories for objects, refs/heads, 26 | refs/tags, and template files. An initial HEAD file that 27 | references the HEAD of the master branch is also created. 28 |

29 |
30 |
31 |

If the $GIT_DIR environment variable is set then it specifies a path 32 | to use instead of ./.git for the base of the repository. 33 |

34 |
35 |
36 |

If the object storage directory is specified via the 37 | $GIT_OBJECT_DIRECTORY environment variable then the sha1 directories 38 | are created underneath - otherwise the default $GIT_DIR/objects 39 | directory is used. 40 |

41 |
42 |
43 |

Running git init in an existing repository is safe. It will not 44 | overwrite things that are already there. The primary reason for 45 | rerunning git init is to pick up newly added templates (or to move 46 | the repository to another place if --separate-git-dir is given). 47 |

48 |
49 |
50 |
51 |
52 |

OPTIONS

53 |
54 |
55 |
56 |
57 |
-q
58 |
--quiet
59 |

Only print error and warning messages, all other output will be suppressed.

60 |
--bare
61 |

Create a bare repository. If GIT_DIR environment is not set, it is set to the 62 | current working directory.

63 |
--template=<template_directory>
64 |

Specify the directory from which templates will be used. (See the "TEMPLATE 65 | DIRECTORY" section below.)

66 |
--separate-git-dir=<git dir>
67 |

Instead of initializing the repository where it is supposed to be, 68 | place a filesytem-agnostic Git symbolic link there, pointing to the 69 | specified path, and initialize a Git repository at the path. The 70 | result is Git repository can be separated from working tree. If this 71 | is reinitialization, the repository will be moved to the specified 72 | path.

73 |
--shared[=(false|true|umask|group|all|world|everybody|0xxx)]
74 |

Specify that the Git repository is to be shared amongst several users. This 75 | allows users belonging to the same group to push into that 76 | repository. When specified, the config variable "core.sharedRepository" is 77 | set so that files and directories under $GIT_DIR are created with the 78 | requested permissions. When not specified, Git will use permissions reported 79 | by umask(2).

80 |
81 |
82 |
83 |

The option can have the following values, defaulting to group if no value 84 | is given: 85 |

86 |
87 |
88 |
    89 |

  • umask (or false): Use permissions reported by umask(2). The default, 90 | when --shared is not specified.

    • 91 |

  • group (or true): Make the repository group-writable, (and g+sx, since 92 | the git group may be not the primary group of all users). 93 | This is used to loosen the permissions of an otherwise safe umask(2) value. 94 | Note that the umask still applies to the other permission bits (e.g. if 95 | umask is 0022, using group will not remove read privileges from other 96 | (non-group) users). See 0xxx for how to exactly specify the repository 97 | permissions.

    • 98 |

  • all (or world or everybody): Same as group, but make the repository 99 | readable by all users.

    • 100 |

  • 0xxx: 0xxx is an octal number and each file will have mode 0xxx. 101 | 0xxx will override users' umask(2) value (and not only loosen permissions 102 | as group and all does). 0640 will create a repository which is 103 | group-readable, but not group-writable or accessible to others. 0660 will 104 | create a repo that is readable and writable to the current user and group, 105 | but inaccessible to others.

    • 106 |
107 |
108 |
109 |

By default, the configuration flag receive.denyNonFastForwards is enabled 110 | in shared repositories, so that you cannot force a non fast-forwarding push 111 | into it. 112 |

113 |
114 |
115 |

If you name a (possibly non-existent) directory at the end of the command 116 | line, the command is run inside the directory (possibly after creating it). 117 |

118 |
119 |
120 |
121 |
122 |
123 |
124 |

TEMPLATE DIRECTORY

125 |
126 |

The template directory contains files and directories that will be copied to 127 | the $GIT_DIR after it is created. 128 |

129 |
130 |
131 |

The template directory used will (in order): 132 |

133 |
134 |
135 |
    136 |

  • The argument given with the --template option.

    • 137 |

  • The contents of the $GIT_TEMPLATE_DIR environment variable.

    • 138 |

  • The init.templatedir configuration variable.

    • 139 |

  • The default template directory: /usr/share/git-core/templates.

    • 140 |
141 |
142 |
143 |

The default template directory includes some directory structure, some 144 | suggested "exclude patterns", and copies of sample "hook" files. 145 | The suggested patterns and hook files are all modifiable and extensible. 146 |

147 |
148 |
149 |
150 |
151 |

EXAMPLES

152 |
153 |
154 |
Start a new Git repository for an existing code base
155 |
156 |
157 | 
$ cd /path/to/my/codebase
158 | $ git init      <1>
159 | $ git add .     <2>
160 |
161 |
162 |
163 |
164 |

165 |
166 |
167 |
    168 |

  1. prepare /path/to/my/codebase/.git directory

    2. 169 |

  2. add all existing file to the index

    3. 170 |
171 |
172 |
173 |
174 |
175 |
176 |
177 |
178 |

GIT

179 |
180 |

Part of the git(1) suite 181 |

182 |
183 |
184 |
185 |
186 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-instaweb.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git instaweb [--local] [--httpd=<httpd>] [--port=<port>]
 16 | [--browser=<browser>]
 17 | git instaweb [--start] [--stop] [--restart]
18 |
19 |
20 |
21 |
22 |

DESCRIPTION

23 |
24 |

A simple script to set up gitweb and a web server for browsing the local 25 | repository. 26 |

27 |
28 |
29 |
30 |
31 |

OPTIONS

32 |
33 |
34 |
-l
35 |
--local
36 |

Only bind the web server to the local IP (127.0.0.1).

37 |
-d
38 |
--httpd
39 |

The HTTP daemon command-line that will be executed. 40 | Command-line options may be specified here, and the 41 | configuration file will be added at the end of the command-line. 42 | Currently apache2, lighttpd, mongoose, plackup and webrick are supported. 43 | (Default: lighttpd)

44 |
-m
45 |
--module-path
46 |

The module path (only needed if httpd is Apache). 47 | (Default: /usr/lib/apache2/modules)

48 |
-p
49 |
--port
50 |

The port number to bind the httpd to. (Default: 1234)

51 |
-b
52 |
--browser
53 |

The web browser that should be used to view the gitweb 54 | page. This will be passed to the git web--browse helper 55 | script along with the URL of the gitweb instance. See 56 | git-web--browse(1) for more information about this. If 57 | the script fails, the URL will be printed to stdout.

58 |
start
59 |
--start
60 |

Start the httpd instance and exit. Regenerate configuration files 61 | as necessary for spawning a new instance.

62 |
stop
63 |
--stop
64 |

Stop the httpd instance and exit. This does not generate 65 | any of the configuration files for spawning a new instance, 66 | nor does it close the browser.

67 |
restart
68 |
--restart
69 |

Restart the httpd instance and exit. Regenerate configuration files 70 | as necessary for spawning a new instance.

71 |
72 |
73 |
74 |
75 |
76 |

CONFIGURATION

77 |
78 |

You may specify configuration in your .git/config 79 |

80 |
81 |
82 |
83 | 
[instaweb]
 84 | 	local = true
 85 | 	httpd = apache2 -f
 86 | 	port = 4321
 87 | 	browser = konqueror
 88 | 	modulepath = /usr/lib/apache2/modules
 89 | 
 90 |
91 |
92 |
93 |
94 |

If the configuration variable instaweb.browser is not set, 95 | web.browser will be used instead if it is defined. See 96 | git-web--browse(1) for more information about this. 97 |

98 |
99 |
100 |
101 |
102 |

SEE ALSO

103 |
104 |

gitweb(1) 105 |

106 |
107 |
108 |
109 |
110 |

GIT

111 |
112 |

Part of the git(1) suite 113 |

114 |
115 |
116 |
117 |
118 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-merge-base.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git merge-base [-a|--all] <commit> <commit>...
 16 | git merge-base [-a|--all] --octopus <commit>...
 17 | git merge-base --is-ancestor <commit> <commit>
 18 | git merge-base --independent <commit>...
19 |
20 |
21 |
22 |
23 |

DESCRIPTION

24 |
25 |

git merge-base finds best common ancestor(s) between two commits to use 26 | in a three-way merge. One common ancestor is better than another common 27 | ancestor if the latter is an ancestor of the former. A common ancestor 28 | that does not have any better common ancestor is a best common 29 | ancestor, i.e. a merge base. Note that there can be more than one 30 | merge base for a pair of commits. 31 |

32 |
33 |
34 |
35 |
36 |

OPERATION MODE

37 |
38 |

As the most common special case, specifying only two commits on the 39 | command line means computing the merge base between the given two commits. 40 |

41 |
42 |
43 |

More generally, among the two commits to compute the merge base from, 44 | one is specified by the first commit argument on the command line; 45 | the other commit is a (possibly hypothetical) commit that is a merge 46 | across all the remaining commits on the command line. 47 |

48 |
49 |
50 |

As a consequence, the merge base is not necessarily contained in each of the 51 | commit arguments if more than two commits are specified. This is different 52 | from git-show-branch(1) when used with the --merge-base option. 53 |

54 |
55 |
56 |
57 |
--octopus
58 |

Compute the best common ancestors of all supplied commits, 59 | in preparation for an n-way merge. This mimics the behavior 60 | of git show-branch --merge-base.

61 |
--independent
62 |

Instead of printing merge bases, print a minimal subset of 63 | the supplied commits with the same ancestors. In other words, 64 | among the commits given, list those which cannot be reached 65 | from any other. This mimics the behavior of git show-branch 66 | --independent.

67 |
--is-ancestor
68 |

Check if the first <commit> is an ancestor of the second <commit>, 69 | and exit with status 0 if true, or with status 1 if not. 70 | Errors are signaled by a non-zero status that is not 1.

71 |
72 |
73 |
74 |
75 |
76 |

OPTIONS

77 |
78 |
79 |
-a
80 |
--all
81 |

Output all merge bases for the commits, instead of just one.

82 |
83 |
84 |
85 |
86 |
87 |

DISCUSSION

88 |
89 |

Given two commits A and B, git merge-base A B will output a commit 90 | which is reachable from both A and B through the parent relationship. 91 |

92 |
93 |
94 |

For example, with this topology: 95 |

96 |
97 |
98 |
99 | 
		 o---o---o---B
100 | 		/
101 | 	---o---1---o---o---o---A
102 |
103 |
104 |
105 |
106 |

the merge base between A and B is 1. 107 |

108 |
109 |
110 |

Given three commits A, B and C, git merge-base A B C will compute the 111 | merge base between A and a hypothetical commit M, which is a merge 112 | between B and C. For example, with this topology: 113 |

114 |
115 |
116 |
117 | 
	       o---o---o---o---C
118 | 	      /
119 | 	     /   o---o---o---B
120 | 	    /   /
121 | 	---2---1---o---o---o---A
122 |
123 |
124 |
125 |
126 |

the result of git merge-base A B C is 1. This is because the 127 | equivalent topology with a merge commit M between B and C is: 128 |

129 |
130 |
131 |
132 | 
	       o---o---o---o---o
133 | 	      /                 \
134 | 	     /   o---o---o---o---M
135 | 	    /   /
136 | 	---2---1---o---o---o---A
137 |
138 |
139 |
140 |
141 |

and the result of git merge-base A M is 1. Commit 2 is also a 142 | common ancestor between A and M, but 1 is a better common ancestor, 143 | because 2 is an ancestor of 1. Hence, 2 is not a merge base. 144 |

145 |
146 |
147 |

The result of git merge-base --octopus A B C is 2, because 2 is 148 | the best common ancestor of all commits. 149 |

150 |
151 |
152 |

When the history involves criss-cross merges, there can be more than one 153 | best common ancestor for two commits. For example, with this topology: 154 |

155 |
156 |
157 |
158 | 
       ---1---o---A
159 | 	   \ /
160 | 	    X
161 | 	   / \
162 |        ---2---o---o---B
163 |
164 |
165 |
166 |
167 |

both 1 and 2 are merge-bases of A and B. Neither one is better than 168 | the other (both are best merge bases). When the --all option is not given, 169 | it is unspecified which best one is output. 170 |

171 |
172 |
173 |

A common idiom to check "fast-forward-ness" between two commits A 174 | and B is (or at least used to be) to compute the merge base between 175 | A and B, and check if it is the same as A, in which case, A is an 176 | ancestor of B. You will see this idiom used often in older scripts. 177 |

178 |
179 |
180 |
181 | 
	A=$(git rev-parse --verify A)
182 | 	if test "$A" = "$(git merge-base A B)"
183 | 	then
184 | 		... A is an ancestor of B ...
185 | 	fi
186 |
187 |
188 |
189 |
190 |

In modern git, you can say this in a more direct way: 191 |

192 |
193 |
194 |
195 | 
	if git merge-base --is-ancestor A B
196 | 	then
197 | 		... A is an ancestor of B ...
198 | 	fi
199 |
200 |
201 |
202 |
203 |

instead. 204 |

205 |
206 |
207 |
208 |
209 |

See also

210 |
211 |

git-rev-list(1), 212 | git-show-branch(1), 213 | git-merge(1) 214 |

215 |
216 |
217 |
218 |
219 |

GIT

220 |
221 |

Part of the git(1) suite 222 |

223 |
224 |
225 |
226 |
227 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-mergetool.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git mergetool [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
16 |
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

Use git mergetool to run one of several merge utilities to resolve 23 | merge conflicts. It is typically run after git merge. 24 |

25 |
26 |
27 |

If one or more <file> parameters are given, the merge tool program will 28 | be run to resolve differences on each file (skipping those without 29 | conflicts). Specifying a directory will include all unresolved files in 30 | that path. If no <file> names are specified, git mergetool will run 31 | the merge tool program on every file with merge conflicts. 32 |

33 |
34 |
35 |
36 |
37 |

OPTIONS

38 |
39 |
40 |
-t <tool>
41 |
--tool=<tool>
42 |

Use the merge resolution program specified by <tool>. 43 | Valid values include emerge, gvimdiff, kdiff3, 44 | meld, vimdiff, and tortoisemerge. Run git mergetool --tool-help 45 | for the list of valid <tool> settings.

46 |

47 |
48 |
49 |

If a merge resolution program is not specified, git mergetool 50 | will use the configuration variable merge.tool. If the 51 | configuration variable merge.tool is not set, git mergetool 52 | will pick a suitable default. 53 |

54 |
55 |
56 |

You can explicitly provide a full path to the tool by setting the 57 | configuration variable mergetool.<tool>.path. For example, you 58 | can configure the absolute path to kdiff3 by setting 59 | mergetool.kdiff3.path. Otherwise, git mergetool assumes the 60 | tool is available in PATH. 61 |

62 |
63 |
64 |

Instead of running one of the known merge tool programs, 65 | git mergetool can be customized to run an alternative program 66 | by specifying the command line to invoke in a configuration 67 | variable mergetool.<tool>.cmd. 68 |

69 |
70 |
71 |

When git mergetool is invoked with this tool (either through the 72 | -t or --tool option or the merge.tool configuration 73 | variable) the configured command line will be invoked with $BASE 74 | set to the name of a temporary file containing the common base for 75 | the merge, if available; $LOCAL set to the name of a temporary 76 | file containing the contents of the file on the current branch; 77 | $REMOTE set to the name of a temporary file containing the 78 | contents of the file to be merged, and $MERGED set to the name 79 | of the file to which the merge tool should write the result of the 80 | merge resolution. 81 |

82 |
83 |
84 |

If the custom merge tool correctly indicates the success of a 85 | merge resolution with its exit code, then the configuration 86 | variable mergetool.<tool>.trustExitCode can be set to true. 87 | Otherwise, git mergetool will prompt the user to indicate the 88 | success of the resolution after the custom tool has exited. 89 |

90 |
91 |
92 |
--tool-help
93 |

Print a list of merge tools that may be used with --tool.

94 |
-y
95 |
--no-prompt
96 |

Don't prompt before each invocation of the merge resolution 97 | program.

98 |
--prompt
99 |

Prompt before each invocation of the merge resolution program. 100 | This is the default behaviour; the option is provided to 101 | override any configuration settings.

102 |
103 |
104 |
105 |
106 |
107 |

TEMPORARY FILES

108 |
109 |

git mergetool creates *.orig backup files while resolving merges. 110 | These are safe to remove once a file has been merged and its 111 | git mergetool session has completed. 112 |

113 |
114 |
115 |

Setting the mergetool.keepBackup configuration variable to false 116 | causes git mergetool to automatically remove the backup as files 117 | are successfully merged. 118 |

119 |
120 |
121 |
122 |
123 |

GIT

124 |
125 |

Part of the git(1) suite 126 |

127 |
128 |
129 |
130 |
131 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-mv.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git mv <options>... <args>...
16 |
17 |
18 |
19 |

DESCRIPTION

20 |
21 |

Move or rename a file, directory or symlink. 22 |

23 |
24 |
25 |
26 | 
 git mv [-v] [-f] [-n] [-k] <source> <destination>
27 |  git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
28 |
29 |
30 |
31 |
32 |

In the first form, it renames <source>, which must exist and be either 33 | a file, symlink or directory, to <destination>. 34 | In the second form, the last argument has to be an existing 35 | directory; the given sources will be moved into this directory. 36 |

37 |
38 |
39 |

The index is updated after successful completion, but the change must still be 40 | committed. 41 |

42 |
43 |
44 |
45 |

OPTIONS

46 |
47 |
48 |
-f
49 |
--force
50 |

Force renaming or moving of a file even if the target exists

51 |
-k
52 |

Skip move or rename actions which would lead to an error 53 | condition. An error happens when a source is neither existing nor 54 | controlled by Git, or when it would overwrite an existing 55 | file unless -f is given.

56 |
-n
57 |
--dry-run
58 |

Do nothing; only show what would happen

59 |
-v
60 |
--verbose
61 |

Report the names of files as they are moved.

62 |
63 |
64 |
65 |
66 |

SUBMODULES

67 |
68 |

Moving a submodule using a gitfile (which means they were cloned 69 | with a Git version 1.7.8 or newer) will update the gitfile and 70 | core.worktree setting to make the submodule work in the new location. 71 | It also will attempt to update the submodule.<name>.path setting in 72 | the gitmodules(5) file and stage that file (unless -n is used). 73 |

74 |
75 |
76 |
77 |

GIT

78 |
79 |

Part of the git(1) suite 80 |

81 |
82 |
83 |
84 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-reflog.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git reflog <subcommand> <options>
16 |
17 |
18 |
19 |

DESCRIPTION

20 |
21 |

The command takes various subcommands, and different options 22 | depending on the subcommand: 23 |

24 |
25 |
26 | 
git reflog expire [--dry-run] [--stale-fix] [--verbose]
 27 | [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
 28 | git reflog delete ref@{specifier}...
 29 | git reflog [show] [log-options] [<ref>]
30 |
31 |
32 |

Reflog is a mechanism to record when the tip of branches are 33 | updated. This command is to manage the information recorded in it. 34 |

35 |
36 |
37 |

The subcommand "expire" is used to prune older reflog entries. 38 | Entries older than expire time, or entries older than 39 | expire-unreachable time and not reachable from the current 40 | tip, are removed from the reflog. This is typically not used 41 | directly by the end users -- instead, see git-gc(1). 42 |

43 |
44 |
45 |

The subcommand "show" (which is also the default, in the absence of any 46 | subcommands) will take all the normal log options, and show the log of 47 | the reference provided in the command-line (or HEAD, by default). 48 | The reflog will cover all recent actions (HEAD reflog records branch switching 49 | as well). It is an alias for git log -g --abbrev-commit --pretty=oneline; 50 | see git-log(1). 51 |

52 |
53 |
54 |

The reflog is useful in various Git commands, to specify the old value 55 | of a reference. For example, HEAD@{2} means "where HEAD used to be 56 | two moves ago", master@{one.week.ago} means "where master used to 57 | point to one week ago", and so on. See gitrevisions(7) for 58 | more details. 59 |

60 |
61 |
62 |

To delete single entries from the reflog, use the subcommand "delete" 63 | and specify the exact entry (e.g. "git reflog delete master@{2}"). 64 |

65 |
66 |
67 |
68 |

OPTIONS

69 |
70 |
71 |
--stale-fix
72 |

This revamps the logic -- the definition of "broken commit" 73 | becomes: a commit that is not reachable from any of the refs and 74 | there is a missing object among the commit, tree, or blob 75 | objects reachable from it that is not reachable from any of the 76 | refs.

77 |

78 |
79 |
80 |

This computation involves traversing all the reachable objects, i.e. it 81 | has the same cost as git prune. Fortunately, once this is run, we 82 | should not have to ever worry about missing objects, because the current 83 | prune and pack-objects know about reflogs and protect objects referred by 84 | them. 85 |

86 |
87 |
88 |
--expire=<time>
89 |

Entries older than this time are pruned. Without the 90 | option it is taken from configuration gc.reflogExpire, 91 | which in turn defaults to 90 days. --expire=all prunes 92 | entries regardless of their age; --expire=never turns off 93 | pruning of reachable entries (but see --expire-unreachable).

94 |
--expire-unreachable=<time>
95 |

Entries older than this time and not reachable from 96 | the current tip of the branch are pruned. Without the 97 | option it is taken from configuration 98 | gc.reflogExpireUnreachable, which in turn defaults to 99 | 30 days. --expire-unreachable=all prunes unreachable 100 | entries regardless of their age; --expire-unreachable=never 101 | turns off early pruning of unreachable entries (but see 102 | --expire).

103 |
--all
104 |

Instead of listing <refs> explicitly, prune all refs.

105 |
--updateref
106 |

Update the ref with the sha1 of the top reflog entry (i.e. 107 | <ref>@{0}) after expiring or deleting.

108 |
--rewrite
109 |

While expiring or deleting, adjust each reflog entry to ensure 110 | that the old sha1 field points to the new sha1 field of the 111 | previous entry.

112 |
--verbose
113 |

Print extra information on screen.

114 |
115 |
116 |
117 |
118 |

GIT

119 |
120 |

Part of the git(1) suite 121 |

122 |
123 |
124 |
125 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-remote.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git remote [-v | --verbose]
 16 | git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url>
 17 | git remote rename <old> <new>
 18 | git remote remove <name>
 19 | git remote set-head <name> (-a | --auto | -d | --delete | <branch>)
 20 | git remote set-branches [--add] <name> <branch>...
 21 | git remote set-url [--push] <name> <newurl> [<oldurl>]
 22 | git remote set-url --add [--push] <name> <newurl>
 23 | git remote set-url --delete [--push] <name> <url>
 24 | git remote [-v | --verbose] show [-n] <name>...
 25 | git remote prune [-n | --dry-run] <name>...
 26 | git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)...]
27 |
28 |
29 |
30 |

DESCRIPTION

31 |
32 |

Manage the set of repositories ("remotes") whose branches you track. 33 |

34 |
35 |
36 |
37 |

OPTIONS

38 |
39 |
40 |
-v
41 |
--verbose
42 |

Be a little more verbose and show remote url after name. 43 | NOTE: This must be placed between remote and subcommand.

44 |
45 |
46 |
47 |
48 |

COMMANDS

49 |
50 |

With no arguments, shows a list of existing remotes. Several 51 | subcommands are available to perform operations on the remotes. 52 |

53 |
54 |
55 |
56 |
add
57 |

Adds a remote named <name> for the repository at 58 | <url>. The command git fetch <name> can then be used to create and 59 | update remote-tracking branches <name>/<branch>.

60 |

With -f option, git fetch <name> is run immediately after 61 | the remote information is set up. 62 |

63 |
64 |
65 |

With --tags option, git fetch <name> imports every tag from the 66 | remote repository. 67 |

68 |
69 |
70 |

With --no-tags option, git fetch <name> does not import tags from 71 | the remote repository. 72 |

73 |
74 |
75 |

With -t <branch> option, instead of the default glob 76 | refspec for the remote to track all branches under 77 | the refs/remotes/<name>/ namespace, a refspec to track only <branch> 78 | is created. You can give more than one -t <branch> to track 79 | multiple branches without grabbing all branches. 80 |

81 |
82 |
83 |

With -m <master> option, a symbolic-ref refs/remotes/<name>/HEAD is set 84 | up to point at remote's <master> branch. See also the set-head command. 85 |

86 |
87 |
88 |

When a fetch mirror is created with --mirror=fetch, the refs will not 89 | be stored in the refs/remotes/ namespace, but rather everything in 90 | refs/ on the remote will be directly mirrored into refs/ in the 91 | local repository. This option only makes sense in bare repositories, 92 | because a fetch would overwrite any local commits. 93 |

94 |
95 |
96 |

When a push mirror is created with --mirror=push, then git push 97 | will always behave as if --mirror was passed. 98 |

99 |
100 |
101 |
rename
102 |

Rename the remote named <old> to <new>. All remote-tracking branches and 103 | configuration settings for the remote are updated.

104 |

In case <old> and <new> are the same, and <old> is a file under 105 | $GIT_DIR/remotes or $GIT_DIR/branches, the remote is converted to 106 | the configuration file format. 107 |

108 |
109 |
110 |
remove
111 |
rm
112 |

Remove the remote named <name>. All remote-tracking branches and 113 | configuration settings for the remote are removed.

114 |
set-head
115 |

Sets or deletes the default branch (i.e. the target of the 116 | symbolic-ref refs/remotes/<name>/HEAD) for 117 | the named remote. Having a default branch for a remote is not required, 118 | but allows the name of the remote to be specified in lieu of a specific 119 | branch. For example, if the default branch for origin is set to 120 | master, then origin may be specified wherever you would normally 121 | specify origin/master.

122 |

With -d or --delete, the symbolic ref refs/remotes/<name>/HEAD is deleted. 123 |

124 |
125 |
126 |

With -a or --auto, the remote is queried to determine its HEAD, then the 127 | symbolic-ref refs/remotes/<name>/HEAD is set to the same branch. e.g., if the remote 128 | HEAD is pointed at next, "git remote set-head origin -a" will set 129 | the symbolic-ref refs/remotes/origin/HEAD to refs/remotes/origin/next. This will 130 | only work if refs/remotes/origin/next already exists; if not it must be 131 | fetched first. 132 |

133 |
134 |
135 |

Use <branch> to set the symbolic-ref refs/remotes/<name>/HEAD explicitly. e.g., "git 136 | remote set-head origin master" will set the symbolic-ref refs/remotes/origin/HEAD to 137 | refs/remotes/origin/master. This will only work if 138 | refs/remotes/origin/master already exists; if not it must be fetched first. 139 |

140 |
141 |
142 |
set-branches
143 |

Changes the list of branches tracked by the named remote. 144 | This can be used to track a subset of the available remote branches 145 | after the initial setup for a remote.

146 |

The named branches will be interpreted as if specified with the 147 | -t option on the git remote add command line. 148 |

149 |
150 |
151 |

With --add, instead of replacing the list of currently tracked 152 | branches, adds to that list. 153 |

154 |
155 |
156 |
set-url
157 |

Changes URL remote points to. Sets first URL remote points to matching 158 | regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If 159 | <oldurl> doesn't match any URL, error occurs and nothing is changed.

160 |

With --push, push URLs are manipulated instead of fetch URLs. 161 |

162 |
163 |
164 |

With --add, instead of changing some URL, new URL is added. 165 |

166 |
167 |
168 |

With --delete, instead of changing some URL, all URLs matching 169 | regex <url> are deleted. Trying to delete all non-push URLs is an 170 | error. 171 |

172 |
173 |
174 |
show
175 |

Gives some information about the remote <name>.

176 |

With -n option, the remote heads are not queried first with 177 | git ls-remote <name>; cached information is used instead. 178 |

179 |
180 |
181 |
prune
182 |

Deletes all stale remote-tracking branches under <name>. 183 | These stale branches have already been removed from the remote repository 184 | referenced by <name>, but are still locally available in 185 | "remotes/<name>".

186 |

With --dry-run option, report what branches will be pruned, but do not 187 | actually prune them. 188 |

189 |
190 |
191 |
update
192 |

Fetch updates for a named set of remotes in the repository as defined by 193 | remotes.<group>. If a named group is not specified on the command line, 194 | the configuration parameter remotes.default will be used; if 195 | remotes.default is not defined, all remotes which do not have the 196 | configuration parameter remote.<name>.skipDefaultUpdate set to true will 197 | be updated. (See git-config(1)).

198 |

With --prune option, prune all the remotes that are updated. 199 |

200 |
201 |
202 |
203 |
204 |
205 |
206 |

DISCUSSION

207 |
208 |

The remote configuration is achieved using the remote.origin.url and 209 | remote.origin.fetch configuration variables. (See 210 | git-config(1)). 211 |

212 |
213 |
214 |
215 |

Examples

216 |
217 |
    218 |

  • Add a new remote, fetch, and check out a branch from it

    219 |
    220 | 
    $ git remote
221 | origin
222 | $ git branch -r
223 |   origin/HEAD -> origin/master
224 |   origin/master
225 | $ git remote add staging git://git.kernel.org/.../gregkh/staging.git
226 | $ git remote
227 | origin
228 | staging
229 | $ git fetch staging
230 | ...
231 | From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
232 |  * [new branch]      master     -> staging/master
233 |  * [new branch]      staging-linus -> staging/staging-linus
234 |  * [new branch]      staging-next -> staging/staging-next
235 | $ git branch -r
236 |   origin/HEAD -> origin/master
237 |   origin/master
238 |   staging/master
239 |   staging/staging-linus
240 |   staging/staging-next
241 | $ git checkout -b staging staging/master
242 | ...
243 |
    244 |
    245 |
    246 |
    • 247 |

  • Imitate git clone but track only selected branches

    248 |
    249 | 
    $ mkdir project.git
250 | $ cd project.git
251 | $ git init
252 | $ git remote add -f -t master -m master origin git://example.com/git.git/
253 | $ git merge origin
254 |
    255 |
    256 |
    257 |
    • 258 |
259 |
260 |
261 |
262 |

SEE ALSO

263 |
264 |

git-fetch(1) 265 | git-branch(1) 266 | git-config(1) 267 |

268 |
269 |
270 |
271 |

GIT

272 |
273 |

Part of the git(1) suite 274 |

275 |
276 |
277 |
278 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-request-pull.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git request-pull [-p] <start> <url> [<end>]
16 |
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

Summarizes the changes between two commits to the standard output, and includes 23 | the given URL in the generated summary. 24 |

25 |
26 |
27 |
28 |
29 |

OPTIONS

30 |
31 |
32 |
-p
33 |

Show patch text

34 |
<start>
35 |

Commit to start at.

36 |
<url>
37 |

URL to include in the summary.

38 |
<end>
39 |

Commit to end at; defaults to HEAD.

40 |
41 |
42 |
43 |
44 |
45 |

GIT

46 |
47 |

Part of the git(1) suite 48 |

49 |
50 |
51 |
52 |
53 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-rm.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
16 |
17 |
18 |
19 |

DESCRIPTION

20 |
21 |

Remove files from the index, or from the working tree and the index. 22 | git rm will not remove a file from just your working directory. 23 | (There is no option to remove a file only from the working tree 24 | and yet keep it in the index; use /bin/rm if you want to do that.) 25 | The files being removed have to be identical to the tip of the branch, 26 | and no updates to their contents can be staged in the index, 27 | though that default behavior can be overridden with the -f option. 28 | When --cached is given, the staged content has to 29 | match either the tip of the branch or the file on disk, 30 | allowing the file to be removed from just the index. 31 |

32 |
33 |
34 |
35 |

OPTIONS

36 |
37 |
38 |
<file>...
39 |

Files to remove. Fileglobs (e.g. *.c) can be given to 40 | remove all matching files. If you want Git to expand 41 | file glob characters, you may need to shell-escape them. 42 | A leading directory name 43 | (e.g. dir to remove dir/file1 and dir/file2) can be 44 | given to remove all files in the directory, and recursively 45 | all sub-directories, 46 | but this requires the -r option to be explicitly given.

47 |
-f
48 |
--force
49 |

Override the up-to-date check.

50 |
-n
51 |
--dry-run
52 |

Don't actually remove any file(s). Instead, just show 53 | if they exist in the index and would otherwise be removed 54 | by the command.

55 |
-r
56 |

Allow recursive removal when a leading directory name is 57 | given.

58 |
--
59 |

This option can be used to separate command-line options from 60 | the list of files, (useful when filenames might be mistaken 61 | for command-line options).

62 |
--cached
63 |

Use this option to unstage and remove paths only from the index. 64 | Working tree files, whether modified or not, will be 65 | left alone.

66 |
--ignore-unmatch
67 |

Exit with a zero status even if no files matched.

68 |
-q
69 |
--quiet
70 |

git rm normally outputs one line (in the form of an rm command) 71 | for each file removed. This option suppresses that output.

72 |
73 |
74 |
75 |
76 |

DISCUSSION

77 |
78 |

The <file> list given to the command can be exact pathnames, 79 | file glob patterns, or leading directory names. The command 80 | removes only the paths that are known to Git. Giving the name of 81 | a file that you have not told Git about does not remove that file. 82 |

83 |
84 |
85 |

File globbing matches across directory boundaries. Thus, given 86 | two directories d and d2, there is a difference between 87 | using git rm 'd*' and git rm 'd/*', as the former will 88 | also remove all of directory d2. 89 |

90 |
91 |
92 |
93 |

REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM

94 |
95 |

There is no option for git rm to remove from the index only 96 | the paths that have disappeared from the filesystem. However, 97 | depending on the use case, there are several ways that can be 98 | done. 99 |

100 |
101 |
102 |

Using ``git commit -a''

103 |
104 |

If you intend that your next commit should record all modifications 105 | of tracked files in the working tree and record all removals of 106 | files that have been removed from the working tree with rm 107 | (as opposed to git rm), use git commit -a, as it will 108 | automatically notice and record all removals. You can also have a 109 | similar effect without committing by using git add -u. 110 |

111 |
112 |
113 |
114 |

Using ``git add -A''

115 |
116 |

When accepting a new code drop for a vendor branch, you probably 117 | want to record both the removal of paths and additions of new paths 118 | as well as modifications of existing paths. 119 |

120 |
121 |
122 |

Typically you would first remove all tracked files from the working 123 | tree using this command: 124 |

125 |
126 |
127 |
128 | 
git ls-files -z | xargs -0 rm -f
129 |
130 |
131 |
132 |
133 |

and then untar the new code in the working tree. Alternately 134 | you could rsync the changes into the working tree. 135 |

136 |
137 |
138 |

After that, the easiest way to record all removals, additions, and 139 | modifications in the working tree is: 140 |

141 |
142 |
143 |
144 | 
git add -A
145 |
146 |
147 |
148 |
149 |

See git-add(1). 150 |

151 |
152 |
153 |
154 |

Other ways

155 |
156 |

If all you really want to do is to remove from the index the files 157 | that are no longer present in the working tree (perhaps because 158 | your working tree is dirty so that you cannot use git commit -a), 159 | use the following command: 160 |

161 |
162 |
163 |
164 | 
git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
165 |
166 |
167 |
168 |
169 |
170 |
171 |

SUBMODULES

172 |
173 |

Only submodules using a gitfile (which means they were cloned 174 | with a Git version 1.7.8 or newer) will be removed from the work 175 | tree, as their repository lives inside the .git directory of the 176 | superproject. If a submodule (or one of those nested inside it) 177 | still uses a .git directory, git rm will fail - no matter if forced 178 | or not - to protect the submodule's history. If it exists the 179 | submodule.<name> section in the gitmodules(5) file will also 180 | be removed and that file will be staged (unless --cached or -n are used). 181 |

182 |
183 |
184 |

A submodule is considered up-to-date when the HEAD is the same as 185 | recorded in the index, no tracked files are modified and no untracked 186 | files that aren't ignored are present in the submodules work tree. 187 | Ignored files are deemed expendable and won't stop a submodule's work 188 | tree from being removed. 189 |

190 |
191 |
192 |

If you only want to remove the local checkout of a submodule from your 193 | work tree without committing the removal, 194 | use git-submodule(1) deinit instead. 195 |

196 |
197 |
198 |
199 |

EXAMPLES

200 |
201 |
202 |
git rm Documentation/{asterisk}.txt
203 |

Removes all *.txt files from the index that are under the 204 | Documentation directory and any of its subdirectories.

205 |

206 |
207 |
208 |

Note that the asterisk * is quoted from the shell in this 209 | example; this lets Git, and not the shell, expand the pathnames 210 | of files and subdirectories under the Documentation/ directory. 211 |

212 |
213 |
214 |
git rm -f git-*.sh
215 |

Because this example lets the shell expand the asterisk 216 | (i.e. you are listing the files explicitly), it 217 | does not remove subdir/git-foo.sh.

218 |
219 |
220 |
221 |
222 |

SEE ALSO

223 |
224 |

git-add(1) 225 |

226 |
227 |
228 |
229 |

GIT

230 |
231 |

Part of the git(1) suite 232 |

233 |
234 |
235 |
236 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-shortlog.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git log --pretty=short | git shortlog [<options>]
 16 | git shortlog [<options>] [<revision range>] [[--] <path>...]
17 |
18 |
19 |
20 |
21 |

DESCRIPTION

22 |
23 |

Summarizes git log output in a format suitable for inclusion 24 | in release announcements. Each commit will be grouped by author and title. 25 |

26 |
27 |
28 |

Additionally, "[PATCH]" will be stripped from the commit description. 29 |

30 |
31 |
32 |

If no revisions are passed on the command line and either standard input 33 | is not a terminal or there is no current branch, git shortlog will 34 | output a summary of the log read from standard input, without 35 | reference to the current repository. 36 |

37 |
38 |
39 |
40 |
41 |

OPTIONS

42 |
43 |
44 |
-n
45 |
--numbered
46 |

Sort output according to the number of commits per author instead 47 | of author alphabetic order.

48 |
-s
49 |
--summary
50 |

Suppress commit description and provide a commit count summary only.

51 |
-e
52 |
--email
53 |

Show the email address of each author.

54 |
--format[=<format>]
55 |

Instead of the commit subject, use some other information to 56 | describe each commit. <format> can be any string accepted 57 | by the --format option of git log, such as * [%h] %s. 58 | (See the "PRETTY FORMATS" section of git-log(1).)

59 |
60 | 
	Each pretty-printed commit will be rewrapped before it is shown.
 61 |
62 |
63 |
64 |
65 |
-w[<width>[,<indent1>[,<indent2>]]]
66 |

Linewrap the output by wrapping each line at width. The first 67 | line of each entry is indented by indent1 spaces, and the second 68 | and subsequent lines are indented by indent2 spaces. width, 69 | indent1, and indent2 default to 76, 6 and 9 respectively.

70 |

71 |
72 |
73 |

If width is 0 (zero) then indent the lines of the output without wrapping 74 | them. 75 |

76 |
77 |
78 |
<revision range>
79 |

Show only commits in the specified revision range. When no 80 | <revision range> is specified, it defaults to HEAD (i.e. the 81 | whole history leading to the current commit). origin..HEAD 82 | specifies all the commits reachable from the current commit 83 | (i.e. HEAD), but not from origin. For a complete list of 84 | ways to spell <revision range>, see the "Specifying Ranges" 85 | section of gitrevisions(7).

86 |
[--] <path>...
87 |

Consider only commits that are enough to explain how the files 88 | that match the specified paths came to be.

89 |

90 |
91 |
92 |

Paths may need to be prefixed with "-- " to separate them from 93 | options or the revision range, when confusion arises. 94 |

95 |
96 |
97 |
98 |
99 |
100 |
101 |
102 |

MAPPING AUTHORS

103 |
104 |

The .mailmap feature is used to coalesce together commits by the same 105 | person in the shortlog, where their name and/or email address was 106 | spelled differently. 107 |

108 |
109 |
110 |

If the file .mailmap exists at the toplevel of the repository, or at 111 | the location pointed to by the mailmap.file or mailmap.blob 112 | configuration options, it 113 | is used to map author and committer names and email addresses to 114 | canonical real names and email addresses. 115 |

116 |
117 |
118 |

In the simple form, each line in the file consists of the canonical 119 | real name of an author, whitespace, and an email address used in the 120 | commit (enclosed by < and >) to map to the name. For example: 121 |

122 |
123 |
124 |
125 |
126 |
127 | 
	Proper Name <commit@email.xx>
128 |
129 |
130 |
131 |
132 |
133 |
134 |

The more complex forms are: 135 |

136 |
137 |
138 |
139 |
140 |
141 | 
	<proper@email.xx> <commit@email.xx>
142 |
143 |
144 |
145 |
146 |
147 |
148 |

which allows mailmap to replace only the email part of a commit, and: 149 |

150 |
151 |
152 |
153 |
154 |
155 | 
	Proper Name <proper@email.xx> <commit@email.xx>
156 |
157 |
158 |
159 |
160 |
161 |
162 |

which allows mailmap to replace both the name and the email of a 163 | commit matching the specified commit email address, and: 164 |

165 |
166 |
167 |
168 |
169 |
170 | 
	Proper Name <proper@email.xx> Commit Name <commit@email.xx>
171 |
172 |
173 |
174 |
175 |
176 |
177 |

which allows mailmap to replace both the name and the email of a 178 | commit matching both the specified commit name and email address. 179 |

180 |
181 |
182 |

Example 1: Your history contains commits by two authors, Jane 183 | and Joe, whose names appear in the repository under several forms: 184 |

185 |
186 |
187 |
188 | 
Joe Developer <joe@example.com>
189 | Joe R. Developer <joe@example.com>
190 | Jane Doe <jane@example.com>
191 | Jane Doe <jane@laptop.(none)>
192 | Jane D. <jane@desktop.(none)>
193 |
194 |
195 |
196 |
197 |

Now suppose that Joe wants his middle name initial used, and Jane 198 | prefers her family name fully spelled out. A proper .mailmap file 199 | would look like: 200 |

201 |
202 |
203 |
204 | 
Jane Doe         <jane@desktop.(none)>
205 | Joe R. Developer <joe@example.com>
206 |
207 |
208 |
209 |
210 |

Note how there is no need for an entry for <jane@laptop.(none)>, because the 211 | real name of that author is already correct. 212 |

213 |
214 |
215 |

Example 2: Your repository contains commits from the following 216 | authors: 217 |

218 |
219 |
220 |
221 | 
nick1 <bugs@company.xx>
222 | nick2 <bugs@company.xx>
223 | nick2 <nick2@company.xx>
224 | santa <me@company.xx>
225 | claus <me@company.xx>
226 | CTO <cto@coompany.xx>
227 |
228 |
229 |
230 |
231 |

Then you might want a .mailmap file that looks like: 232 |

233 |
234 |
235 |
236 | 
<cto@company.xx>                       <cto@coompany.xx>
237 | Some Dude <some@dude.xx>         nick1 <bugs@company.xx>
238 | Other Author <other@author.xx>   nick2 <bugs@company.xx>
239 | Other Author <other@author.xx>         <nick2@company.xx>
240 | Santa Claus <santa.claus@northpole.xx> <me@company.xx>
241 |
242 |
243 |
244 |
245 |

Use hash # for comments that are either on their own line, or after 246 | the email address. 247 |

248 |
249 |
250 |
251 |
252 |

GIT

253 |
254 |

Part of the git(1) suite 255 |

256 |
257 |
258 |
259 |
260 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-show-ref.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git show-ref [-q|--quiet] [--verify] [--head] [-d|--dereference]
 16 | [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags]
 17 | [--heads] [--] [<pattern>...]
 18 | git show-ref --exclude-existing[=<pattern>] < ref-list
19 |
20 |
21 |
22 |

DESCRIPTION

23 |
24 |

Displays references available in a local repository along with the associated 25 | commit IDs. Results can be filtered using a pattern and tags can be 26 | dereferenced into object IDs. Additionally, it can be used to test whether a 27 | particular ref exists. 28 |

29 |
30 |
31 |

By default, shows the tags, heads, and remote refs. 32 |

33 |
34 |
35 |

The --exclude-existing form is a filter that does the inverse, it shows the 36 | refs from stdin that don't exist in the local repository. 37 |

38 |
39 |
40 |

Use of this utility is encouraged in favor of directly accessing files under 41 | the .git directory. 42 |

43 |
44 |
45 |
46 |

OPTIONS

47 |
48 |
49 |
--head
50 |

Show the HEAD reference, even if it would normally be filtered out.

51 |
--tags
52 |
--heads
53 |

Limit to "refs/heads" and "refs/tags", respectively. These options 54 | are not mutually exclusive; when given both, references stored in 55 | "refs/heads" and "refs/tags" are displayed.

56 |
-d
57 |
--dereference
58 |

Dereference tags into object IDs as well. They will be shown with "^{}" 59 | appended.

60 |
-s
61 |
--hash[=<n>]
62 |

Only show the SHA-1 hash, not the reference name. When combined with 63 | --dereference the dereferenced tag will still be shown after the SHA-1.

64 |
--verify
65 |

Enable stricter reference checking by requiring an exact ref path. 66 | Aside from returning an error code of 1, it will also print an error 67 | message if --quiet was not specified.

68 |
--abbrev[=<n>]
69 |

Abbreviate the object name. When using --hash, you do 70 | not have to say --hash --abbrev; --hash=n would do.

71 |
-q
72 |
--quiet
73 |

Do not print any results to stdout. When combined with --verify this 74 | can be used to silently check if a reference exists.

75 |
--exclude-existing[=<pattern>]
76 |

Make git show-ref act as a filter that reads refs from stdin of the 77 | form "^(?:<anything>\s)?<refname>(?:\^{})?$" 78 | and performs the following actions on each: 79 | (1) strip "^{}" at the end of line if any; 80 | (2) ignore if pattern is provided and does not head-match refname; 81 | (3) warn if refname is not a well-formed refname and skip; 82 | (4) ignore if refname is a ref that exists in the local repository; 83 | (5) otherwise output the line.

84 |
<pattern>...
85 |

Show references matching one or more patterns. Patterns are matched from 86 | the end of the full name, and only complete parts are matched, e.g. 87 | master matches refs/heads/master, refs/remotes/origin/master, 88 | refs/tags/jedi/master but not refs/heads/mymaster nor 89 | refs/remotes/master/jedi.

90 |
91 |
92 |
93 |
94 |

OUTPUT

95 |
96 |

The output is in the format: <SHA-1 ID> <space> <reference name>. 97 |

98 |
99 |
100 |
101 | 
$ git show-ref --head --dereference
102 | 832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD
103 | 832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master
104 | 832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin
105 | 3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c
106 | 6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{}
107 | 055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4
108 | 423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{}
109 | ...
110 |
111 |
112 |
113 |
114 |

When using --hash (and not --dereference) the output format is: <SHA-1 ID> 115 |

116 |
117 |
118 |
119 | 
$ git show-ref --heads --hash
120 | 2e3ba0114a1f52b47df29743d6915d056be13278
121 | 185008ae97960c8d551adcd9e23565194651b5d1
122 | 03adf42c988195b50e1a1935ba5fcbc39b2b029b
123 | ...
124 |
125 |
126 |
127 |
128 |
129 |

EXAMPLE

130 |
131 |

To show all references called "master", whether tags or heads or anything 132 | else, and regardless of how deep in the reference naming hierarchy they are, 133 | use: 134 |

135 |
136 |
137 |
138 | 
	git show-ref master
139 |
140 |
141 |
142 |
143 |

This will show "refs/heads/master" but also "refs/remote/other-repo/master", 144 | if such references exists. 145 |

146 |
147 |
148 |

When using the --verify flag, the command requires an exact path: 149 |

150 |
151 |
152 |
153 | 
	git show-ref --verify refs/heads/master
154 |
155 |
156 |
157 |
158 |

will only match the exact branch called "master". 159 |

160 |
161 |
162 |

If nothing matches, git show-ref will return an error code of 1, 163 | and in the case of verification, it will show an error message. 164 |

165 |
166 |
167 |

For scripting, you can ask it to be quiet with the "--quiet" flag, which 168 | allows you to do things like 169 |

170 |
171 |
172 |
173 | 
	git show-ref --quiet --verify -- "refs/heads/$headname" ||
174 | 		echo "$headname is not a valid branch"
175 |
176 |
177 |
178 |
179 |

to check whether a particular branch exists or not (notice how we don't 180 | actually want to show any results, and we want to use the full refname for it 181 | in order to not trigger the problem with ambiguous partial matches). 182 |

183 |
184 |
185 |

To show only tags, or only proper branch heads, use "--tags" and/or "--heads" 186 | respectively (using both means that it shows tags and heads, but not other 187 | random references under the refs/ subdirectory). 188 |

189 |
190 |
191 |

To do automatic tag object dereferencing, use the "-d" or "--dereference" 192 | flag, so you can do 193 |

194 |
195 |
196 |
197 | 
	git show-ref --tags --dereference
198 |
199 |
200 |
201 |
202 |

to get a listing of all tags together with what they dereference. 203 |

204 |
205 |
206 |
207 |

FILES

208 |
209 |

.git/refs/*, .git/packed-refs 210 |

211 |
212 |
213 |
214 |

SEE ALSO

215 |
216 |

git-ls-remote(1), 217 | git-update-ref(1), 218 | gitrepository-layout(5) 219 |

220 |
221 |
222 |
223 |

GIT

224 |
225 |

Part of the git(1) suite 226 |

227 |
228 |
229 |
230 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-status.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git status [<options>...] [--] [<pathspec>...]
16 |
17 |
18 |
19 |

DESCRIPTION

20 |
21 |

Displays paths that have differences between the index file and the 22 | current HEAD commit, paths that have differences between the working 23 | tree and the index file, and paths in the working tree that are not 24 | tracked by Git (and are not ignored by gitignore(5)). The first 25 | are what you would commit by running git commit; the second and 26 | third are what you could commit by running git add before running 27 | git commit. 28 |

29 |
30 |
31 |
32 |

OPTIONS

33 |
34 |
35 |
-s
36 |
--short
37 |

Give the output in the short-format.

38 |
-b
39 |
--branch
40 |

Show the branch and tracking info even in short-format.

41 |
--porcelain
42 |

Give the output in an easy-to-parse format for scripts. 43 | This is similar to the short output, but will remain stable 44 | across Git versions and regardless of user configuration. See 45 | below for details.

46 |
--long
47 |

Give the output in the long-format. This is the default.

48 |
-u[<mode>]
49 |
--untracked-files[=<mode>]
50 |

Show untracked files.

51 |

52 |
53 |
54 |

The mode parameter is optional (defaults to all), and is used to 55 | specify the handling of untracked files. 56 |

57 |
58 |
59 |

The possible options are: 60 |

61 |
62 |
63 |
    64 |

  • no - Show no untracked files.

    • 65 |

  • normal - Shows untracked files and directories.

    • 66 |

  • all - Also shows individual files in untracked directories.

    67 |

    When -u option is not used, untracked files and directories are 68 | shown (i.e. the same as specifying normal), to help you avoid 69 | forgetting to add newly created files. Because it takes extra work 70 | to find untracked files in the filesystem, this mode may take some 71 | time in a large working tree. You can use no to have git status 72 | return more quickly without showing untracked files. 73 |

    74 |
    75 |
    76 |

    The default can be changed using the status.showUntrackedFiles 77 | configuration variable documented in git-config(1). 78 |

    79 |
    80 |
    • 81 |
82 |
83 |
84 |
--ignore-submodules[=<when>]
85 |

Ignore changes to submodules when looking for changes. <when> can be 86 | either "none", "untracked", "dirty" or "all", which is the default. 87 | Using "none" will consider the submodule modified when it either contains 88 | untracked or modified files or its HEAD differs from the commit recorded 89 | in the superproject and can be used to override any settings of the 90 | ignore option in git-config(1) or gitmodules(5). When 91 | "untracked" is used submodules are not considered dirty when they only 92 | contain untracked content (but they are still scanned for modified 93 | content). Using "dirty" ignores all changes to the work tree of submodules, 94 | only changes to the commits stored in the superproject are shown (this was 95 | the behavior before 1.7.0). Using "all" hides all changes to submodules 96 | (and suppresses the output of submodule summaries when the config option 97 | status.submodulesummary is set).

98 |
--ignored
99 |

Show ignored files as well.

100 |
-z
101 |

Terminate entries with NUL, instead of LF. This implies 102 | the --porcelain output format if no other format is given.

103 |
--column[=<options>]
104 |
--no-column
105 |

Display untracked files in columns. See configuration variable 106 | column.status for option syntax.--column and --no-column 107 | without options are equivalent to always and never 108 | respectively.

109 |
110 |
111 |
112 |
113 |

OUTPUT

114 |
115 |

The output from this command is designed to be used as a commit 116 | template comment, and all the output lines are prefixed with #. 117 | The default, long format, is designed to be human readable, 118 | verbose and descriptive. Its contents and format are subject to change 119 | at any time. 120 |

121 |
122 |
123 |

The paths mentioned in the output, unlike many other Git commands, are 124 | made relative to the current directory if you are working in a 125 | subdirectory (this is on purpose, to help cutting and pasting). See 126 | the status.relativePaths config option below. 127 |

128 |
129 |
130 |

Short Format

131 |
132 |

In the short-format, the status of each path is shown as 133 |

134 |
135 |
136 |
137 | 
	XY PATH1 -> PATH2
138 |
139 |
140 |
141 |
142 |

where PATH1 is the path in the HEAD, and the " -> PATH2" part is 143 | shown only when PATH1 corresponds to a different path in the 144 | index/worktree (i.e. the file is renamed). The XY is a two-letter 145 | status code. 146 |

147 |
148 |
149 |

The fields (including the ->) are separated from each other by a 150 | single space. If a filename contains whitespace or other nonprintable 151 | characters, that field will be quoted in the manner of a C string 152 | literal: surrounded by ASCII double quote (34) characters, and with 153 | interior special characters backslash-escaped. 154 |

155 |
156 |
157 |

For paths with merge conflicts, X and Y show the modification 158 | states of each side of the merge. For paths that do not have merge 159 | conflicts, X shows the status of the index, and Y shows the status 160 | of the work tree. For untracked paths, XY are ??. Other status 161 | codes can be interpreted as follows: 162 |

163 |
164 |
165 |
    166 |

  • = unmodified

    • 167 |

  • M = modified

    • 168 |

  • A = added

    • 169 |

  • D = deleted

    • 170 |

  • R = renamed

    • 171 |

  • C = copied

    • 172 |

  • U = updated but unmerged

    • 173 |
174 |
175 |
176 |

Ignored files are not listed, unless --ignored option is in effect, 177 | in which case XY are !!. 178 |

179 |
180 |
181 |
182 | 
    X          Y     Meaning
183 |     -------------------------------------------------
184 |               [MD]   not updated
185 |     M        [ MD]   updated in index
186 |     A        [ MD]   added to index
187 |     D         [ M]   deleted from index
188 |     R        [ MD]   renamed in index
189 |     C        [ MD]   copied in index
190 |     [MARC]           index and work tree matches
191 |     [ MARC]     M    work tree changed since index
192 |     [ MARC]     D    deleted in work tree
193 |     -------------------------------------------------
194 |     D           D    unmerged, both deleted
195 |     A           U    unmerged, added by us
196 |     U           D    unmerged, deleted by them
197 |     U           A    unmerged, added by them
198 |     D           U    unmerged, deleted by us
199 |     A           A    unmerged, both added
200 |     U           U    unmerged, both modified
201 |     -------------------------------------------------
202 |     ?           ?    untracked
203 |     !           !    ignored
204 |     -------------------------------------------------
205 |
206 |
207 |
208 |
209 |

If -b is used the short-format status is preceded by a line 210 |

211 |
212 |
213 |

## branchname tracking info 214 |

215 |
216 |
217 |
218 |

Porcelain Format

219 |
220 |

The porcelain format is similar to the short format, but is guaranteed 221 | not to change in a backwards-incompatible way between Git versions or 222 | based on user configuration. This makes it ideal for parsing by scripts. 223 | The description of the short format above also describes the porcelain 224 | format, with a few exceptions: 225 |

226 |
227 |
228 |
    229 |

  1. The user's color.status configuration is not respected; color will 230 | always be off.

    2. 231 |

  2. The user's status.relativePaths configuration is not respected; paths 232 | shown will always be relative to the repository root.

    3. 233 |
234 |
235 |
236 |

There is also an alternate -z format recommended for machine parsing. In 237 | that format, the status field is the same, but some other things 238 | change. First, the -> is omitted from rename entries and the field 239 | order is reversed (e.g from -> to becomes to from). Second, a NUL 240 | (ASCII 0) follows each filename, replacing space as a field separator 241 | and the terminating newline (but a space still separates the status 242 | field from the first filename). Third, filenames containing special 243 | characters are not specially formatted; no quoting or 244 | backslash-escaping is performed. 245 |

246 |
247 |
248 |
249 |
250 |

CONFIGURATION

251 |
252 |

The command honors color.status (or status.color -- they 253 | mean the same thing and the latter is kept for backward 254 | compatibility) and color.status.<slot> configuration variables 255 | to colorize its output. 256 |

257 |
258 |
259 |

If the config variable status.relativePaths is set to false, then all 260 | paths shown are relative to the repository root, not to the current 261 | directory. 262 |

263 |
264 |
265 |

If status.submodulesummary is set to a non zero number or true (identical 266 | to -1 or an unlimited number), the submodule summary will be enabled for 267 | the long format and a summary of commits for modified submodules will be 268 | shown (see --summary-limit option of git-submodule(1)). Please note 269 | that the summary output from the status command will be suppressed for all 270 | submodules when diff.ignoreSubmodules is set to all or only for those 271 | submodules where submodule.<name>.ignore=all. To also view the summary for 272 | ignored submodules you can either use the --ignore-submodules=dirty command 273 | line option or the git submodule summary command, which shows a similar 274 | output but does not honor these settings. 275 |

276 |
277 |
278 |
279 |

SEE ALSO

280 |
281 |

gitignore(5) 282 |

283 |
284 |
285 |
286 |

GIT

287 |
288 |

Part of the git(1) suite 289 |

290 |
291 |
292 |
293 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-symbolic-ref.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git symbolic-ref [-m <reason>] <name> <ref>
16 | git symbolic-ref [-q] [--short] <name>
17 | git symbolic-ref --delete [-q] <name>
18 |
19 |
20 |
21 |
22 |

DESCRIPTION

23 |
24 |

Given one argument, reads which branch head the given symbolic 25 | ref refers to and outputs its path, relative to the .git/ 26 | directory. Typically you would give HEAD as the <name> 27 | argument to see which branch your working tree is on. 28 |

29 |
30 |
31 |

Given two arguments, creates or updates a symbolic ref <name> to 32 | point at the given branch <ref>. 33 |

34 |
35 |
36 |

Given --delete and an additional argument, deletes the given 37 | symbolic ref. 38 |

39 |
40 |
41 |

A symbolic ref is a regular file that stores a string that 42 | begins with ref: refs/. For example, your .git/HEAD is 43 | a regular file whose contents is ref: refs/heads/master. 44 |

45 |
46 |
47 |
48 |
49 |

OPTIONS

50 |
51 |
52 |
-d
53 |
--delete
54 |

Delete the symbolic ref <name>.

55 |
-q
56 |
--quiet
57 |

Do not issue an error message if the <name> is not a 58 | symbolic ref but a detached HEAD; instead exit with 59 | non-zero status silently.

60 |
--short
61 |

When showing the value of <name> as a symbolic ref, try to shorten the 62 | value, e.g. from refs/heads/master to master.

63 |
-m
64 |

Update the reflog for <name> with <reason>. This is valid only 65 | when creating or updating a symbolic ref.

66 |
67 |
68 |
69 |
70 |
71 |

NOTES

72 |
73 |

In the past, .git/HEAD was a symbolic link pointing at 74 | refs/heads/master. When we wanted to switch to another branch, 75 | we did ln -sf refs/heads/newbranch .git/HEAD, and when we wanted 76 | to find out which branch we are on, we did readlink .git/HEAD. 77 | But symbolic links are not entirely portable, so they are now 78 | deprecated and symbolic refs (as described above) are used by 79 | default. 80 |

81 |
82 |
83 |

git symbolic-ref will exit with status 0 if the contents of the 84 | symbolic ref were printed correctly, with status 1 if the requested 85 | name is not a symbolic ref, or 128 if another error occurs. 86 |

87 |
88 |
89 |
90 |
91 |

GIT

92 |
93 |

Part of the git(1) suite 94 |

95 |
96 |
97 |
98 |
99 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-update-ref.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git update-ref [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>] | --stdin [-z])
16 |
17 |
18 |
19 |

DESCRIPTION

20 |
21 |

Given two arguments, stores the <newvalue> in the <ref>, possibly 22 | dereferencing the symbolic refs. E.g. git update-ref HEAD 23 | <newvalue> updates the current branch head to the new object. 24 |

25 |
26 |
27 |

Given three arguments, stores the <newvalue> in the <ref>, 28 | possibly dereferencing the symbolic refs, after verifying that 29 | the current value of the <ref> matches <oldvalue>. 30 | E.g. git update-ref refs/heads/master <newvalue> <oldvalue> 31 | updates the master branch head to <newvalue> only if its current 32 | value is <oldvalue>. You can specify 40 "0" or an empty string 33 | as <oldvalue> to make sure that the ref you are creating does 34 | not exist. 35 |

36 |
37 |
38 |

It also allows a "ref" file to be a symbolic pointer to another 39 | ref file by starting with the four-byte header sequence of 40 | "ref:". 41 |

42 |
43 |
44 |

More importantly, it allows the update of a ref file to follow 45 | these symbolic pointers, whether they are symlinks or these 46 | "regular file symbolic refs". It follows real symlinks only 47 | if they start with "refs/": otherwise it will just try to read 48 | them and update them as a regular file (i.e. it will allow the 49 | filesystem to follow them, but will overwrite such a symlink to 50 | somewhere else with a regular filename). 51 |

52 |
53 |
54 |

If --no-deref is given, <ref> itself is overwritten, rather than 55 | the result of following the symbolic pointers. 56 |

57 |
58 |
59 |

In general, using 60 |

61 |
62 |
63 |
64 | 
	git update-ref HEAD "$head"
 65 |
66 |
67 |
68 |
69 |

should be a lot safer than doing 70 |

71 |
72 |
73 |
74 | 
	echo "$head" > "$GIT_DIR/HEAD"
 75 |
76 |
77 |
78 |
79 |

both from a symlink following standpoint and an error checking 80 | standpoint. The "refs/" rule for symlinks means that symlinks 81 | that point to "outside" the tree are safe: they'll be followed 82 | for reading but not for writing (so we'll never write through a 83 | ref symlink to some other tree, if you have copied a whole 84 | archive by creating a symlink tree). 85 |

86 |
87 |
88 |

With -d flag, it deletes the named <ref> after verifying it 89 | still contains <oldvalue>. 90 |

91 |
92 |
93 |

With --stdin, update-ref reads instructions from standard input and 94 | performs all modifications together. Specify commands of the form: 95 |

96 |
97 |
98 |
99 | 
	update SP <ref> SP <newvalue> [SP <oldvalue>] LF
100 | 	create SP <ref> SP <newvalue> LF
101 | 	delete SP <ref> [SP <oldvalue>] LF
102 | 	verify SP <ref> [SP <oldvalue>] LF
103 | 	option SP <opt> LF
104 |
105 |
106 |
107 |
108 |

Quote fields containing whitespace as if they were strings in C source 109 | code. Alternatively, use -z to specify commands without quoting: 110 |

111 |
112 |
113 |
114 | 
	update SP <ref> NUL <newvalue> NUL [<oldvalue>] NUL
115 | 	create SP <ref> NUL <newvalue> NUL
116 | 	delete SP <ref> NUL [<oldvalue>] NUL
117 | 	verify SP <ref> NUL [<oldvalue>] NUL
118 | 	option SP <opt> NUL
119 |
120 |
121 |
122 |
123 |

Lines of any other format or a repeated <ref> produce an error. 124 | Command meanings are: 125 |

126 |
127 |
128 |
129 |
update
130 |

Set <ref> to <newvalue> after verifying <oldvalue>, if given. 131 | Specify a zero <newvalue> to ensure the ref does not exist 132 | after the update and/or a zero <oldvalue> to make sure the 133 | ref does not exist before the update.

134 |
create
135 |

Create <ref> with <newvalue> after verifying it does not 136 | exist. The given <newvalue> may not be zero.

137 |
delete
138 |

Delete <ref> after verifying it exists with <oldvalue>, if 139 | given. If given, <oldvalue> may not be zero.

140 |
verify
141 |

Verify <ref> against <oldvalue> but do not change it. If 142 | <oldvalue> zero or missing, the ref must not exist.

143 |
option
144 |

Modify behavior of the next command naming a <ref>. 145 | The only valid option is no-deref to avoid dereferencing 146 | a symbolic ref.

147 |
148 |
149 |
150 |

Use 40 "0" or the empty string to specify a zero value, except that 151 | with -z an empty <oldvalue> is considered missing. 152 |

153 |
154 |
155 |

If all <ref>s can be locked with matching <oldvalue>s 156 | simultaneously, all modifications are performed. Otherwise, no 157 | modifications are performed. Note that while each individual 158 | <ref> is updated or deleted atomically, a concurrent reader may 159 | still see a subset of the modifications. 160 |

161 |
162 |
163 |
164 |

Logging Updates

165 |
166 |

If config parameter "core.logAllRefUpdates" is true and the ref is one under 167 | "refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or 168 | the file "$GIT_DIR/logs/<ref>" exists then git update-ref will append 169 | a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all 170 | symbolic refs before creating the log name) describing the change 171 | in ref value. Log lines are formatted as: 172 |

173 |
174 |
175 |
    176 |

  1. oldsha1 SP newsha1 SP committer LF

    177 |

    Where "oldsha1" is the 40 character hexadecimal value previously 178 | stored in <ref>, "newsha1" is the 40 character hexadecimal value of 179 | <newvalue> and "committer" is the committer's name, email address 180 | and date in the standard Git committer ident format. 181 |

    182 |
    183 |
    2. 184 |
185 |
186 |
187 |

Optionally with -m: 188 |

189 |
190 |
191 |
    192 |

  1. oldsha1 SP newsha1 SP committer TAB message LF

    193 |

    Where all fields are as described above and "message" is the 194 | value supplied to the -m option. 195 |

    196 |
    197 |
    2. 198 |
199 |
200 |
201 |

An update will fail (without changing <ref>) if the current user is 202 | unable to create a new log file, append to the existing log file 203 | or does not have committer information available. 204 |

205 |
206 |
207 |
208 |

GIT

209 |
210 |

Part of the git(1) suite 211 |

212 |
213 |
214 |
215 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-update-server-info.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git update-server-info [--force]
16 |
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

A dumb server that does not do on-the-fly pack generations must 23 | have some auxiliary information files in $GIT_DIR/info and 24 | $GIT_OBJECT_DIRECTORY/info directories to help clients discover 25 | what references and packs the server has. This command 26 | generates such auxiliary files. 27 |

28 |
29 |
30 |
31 |
32 |

OPTIONS

33 |
34 |
35 |
-f
36 |
--force
37 |

Update the info files from scratch.

38 |
39 |
40 |
41 |
42 |
43 |

OUTPUT

44 |
45 |

Currently the command updates the following files. Please see 46 | gitrepository-layout(5) for description of 47 | what they are for: 48 |

49 |
50 |
51 |
    52 |

  • objects/info/packs

    • 53 |

  • info/refs

    • 54 |
55 |
56 |
57 |
58 |
59 |

GIT

60 |
61 |

Part of the git(1) suite 62 |

63 |
64 |
65 |
66 |
67 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-verify-pack.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git verify-pack [-v|--verbose] [-s|--stat-only] [--] <pack>.idx ...
16 |
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

Reads given idx file for packed Git archive created with the 23 | git pack-objects command and verifies idx file and the 24 | corresponding pack file. 25 |

26 |
27 |
28 |
29 |
30 |

OPTIONS

31 |
32 |
33 |
<pack>.idx ...
34 |

The idx files to verify.

35 |
-v
36 |
--verbose
37 |

After verifying the pack, show list of objects contained 38 | in the pack and a histogram of delta chain length.

39 |
-s
40 |
--stat-only
41 |

Do not verify the pack contents; only show the histogram of delta 42 | chain length. With --verbose, list of objects is also shown.

43 |
--
44 |

Do not interpret any more arguments as options.

45 |
46 |
47 |
48 |
49 |
50 |

OUTPUT FORMAT

51 |
52 |

When specifying the -v option the format used is: 53 |

54 |
55 |
56 |
57 | 
	SHA-1 type size size-in-pack-file offset-in-packfile
58 |
59 |
60 |
61 |
62 |

for objects that are not deltified in the pack, and 63 |

64 |
65 |
66 |
67 | 
	SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1
68 |
69 |
70 |
71 |
72 |

for objects that are deltified. 73 |

74 |
75 |
76 |
77 |
78 |

GIT

79 |
80 |

Part of the git(1) suite 81 |

82 |
83 |
84 |
85 |
86 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/docs/git-write-tree.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 12 |
13 |

SYNOPSIS

14 |
15 | 
git write-tree [--missing-ok] [--prefix=<prefix>/]
16 |
17 |
18 |
19 |
20 |

DESCRIPTION

21 |
22 |

Creates a tree object using the current index. The name of the new 23 | tree object is printed to standard output. 24 |

25 |
26 |
27 |

The index must be in a fully merged state. 28 |

29 |
30 |
31 |

Conceptually, git write-tree sync()s the current index contents 32 | into a set of tree files. 33 | In order to have that match what is actually in your directory right 34 | now, you need to have done a git update-index phase before you did the 35 | git write-tree. 36 |

37 |
38 |
39 |
40 |
41 |

OPTIONS

42 |
43 |
44 |
--missing-ok
45 |

Normally git write-tree ensures that the objects referenced by the 46 | directory exist in the object database. This option disables this 47 | check.

48 |
--prefix=<prefix>/
49 |

Writes a tree object that represents a subdirectory 50 | <prefix>. This can be used to write the tree object 51 | for a subproject that is in the named subdirectory.

52 |
53 |
54 |
55 |
56 |
57 |

GIT

58 |
59 |

Part of the git(1) suite 60 |

61 |
62 |
63 |
64 |
65 |
-------------------------------------------------------------------------------- /Git.docset/Contents/Resources/Documents/index.html: -------------------------------------------------------------------------------- 1 |
2 |

Reference

3 |
4 |

5 | Quick reference guides: 6 | Heroku Cheat Sheet 7 | (PDF)  |  8 | Visual Git Cheat Sheet 9 | (SVG | PNG) 10 |

11 |
12 |
13 |
14 |
15 |

Setup and Config

16 | 20 |

Getting and Creating Projects

21 | 25 |

Basic Snapshotting

26 | 35 |

Branching and Merging

36 | 45 | 46 | 53 |

Inspection and Comparison

54 | 61 |

Patching

62 | 68 |
69 |
70 |

Debugging

71 | 76 | 77 | 84 |

External Systems

85 | 89 |

Administration

90 | 99 |

Server Admin

100 | 104 |

Plumbing Commands

105 | 122 |
123 |
124 |
125 |
126 | -------------------------------------------------------------------------------- /Git.docset/Contents/Resources/docSet.dsidx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iamaziz/git-dash/5094f4e82fe61984265391c916d545705cb740c9/Git.docset/Contents/Resources/docSet.dsidx -------------------------------------------------------------------------------- /Git.docset/Contents/info.plist: -------------------------------------------------------------------------------- 1 | CFBundleIdentifier Git CFBundleName Git DocSetPlatformFamily Git isDashDocset dashIndexFilePath index.html -------------------------------------------------------------------------------- /Git.docset/icon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iamaziz/git-dash/5094f4e82fe61984265391c916d545705cb740c9/Git.docset/icon.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Dash docset of Git commands 2 | 3 | [Git commands reference](http://git-scm.com/docs) docset for [Dash](http://kapeli.com/dash). 4 | 5 | 6 | #### Screenshot 7 | ![Git Commands Reference docset](/screenshot.png) 8 | -------------------------------------------------------------------------------- /git-gendoc2dash.py: -------------------------------------------------------------------------------- 1 | """ 2 | Generate Dash docset for Git 3 | http://git-scm.com/docs 4 | """ 5 | import sqlite3 6 | import os 7 | import urllib 8 | from bs4 import BeautifulSoup as bs 9 | import requests 10 | 11 | 12 | # CONFIGURATION 13 | docset_name = 'Git.docset' 14 | output = docset_name + '/Contents/Resources/Documents' 15 | root_url = 'http://git-scm.com/docs' 16 | 17 | # create directory 18 | docpath = output + '/' 19 | if not os.path.exists(docpath): os.makedirs(docpath) 20 | icon = 'http://blog.novatec-gmbh.de/wp-content/uploads/2013/07/logo-git.png' 21 | 22 | # soup 23 | data = requests.get(root_url).text # for online page 24 | soup = bs(data) 25 | index = str(soup.find(id='main')) 26 | open(os.path.join(output, 'index.html'), 'wb').write(index) 27 | # add icon 28 | urllib.urlretrieve(icon, docset_name + "/icon.png") 29 | 30 | 31 | def update_db(name, path): 32 | typ = 'func' 33 | cur.execute('INSERT OR IGNORE INTO searchIndex(name, type, path) VALUES (?,?,?)', (name, typ, path)) 34 | print 'DB add >> name: %s, path: %s' % (name, path) 35 | 36 | 37 | def add_docs(): 38 | sections = [] 39 | titles = [] 40 | for i, link in enumerate(soup.findAll('a')): 41 | name = link.text.strip() 42 | path = link.get('href') 43 | 44 | if path.startswith('/docs/'): 45 | sections.append(path) 46 | titles.append(name) 47 | 48 | # download and update db 49 | for path, name in zip(sections, titles): 50 | # create subdir 51 | folder = os.path.join(output) 52 | for i in range(len(path.split("/")) - 1): 53 | folder += path.split("/")[i] + "/" 54 | if not os.path.exists(folder): os.makedirs(folder) 55 | 56 | print name, path 57 | try: 58 | # download docs 59 | page = path.split('/')[-1] 60 | url = root_url + '/' + page 61 | 62 | data1 = requests.get(url).text 63 | soup1 = bs(data1) 64 | div = str(soup1.find(id='main')) 65 | open(os.path.join(folder, page + '.html'), 'wb').write(div) 66 | print "downloaded doc: ", path 67 | print " V" 68 | 69 | # update db 70 | path += '.html' 71 | update_db(name, path) 72 | #y += 1 73 | except: 74 | print " X" 75 | pass 76 | 77 | 78 | def add_infoplist(): 79 | name = docset_name.split('.')[0] 80 | info = " " \ 81 | " " \ 82 | " " \ 83 | " " \ 84 | " CFBundleIdentifier " \ 85 | " {0} " \ 86 | " CFBundleName " \ 87 | " {1}" \ 88 | " DocSetPlatformFamily" \ 89 | " {2}" \ 90 | " isDashDocset" \ 91 | " " \ 92 | " dashIndexFilePath" \ 93 | " index.html" \ 94 | "" \ 95 | "".format(name, name, name) 96 | open(docset_name + '/Contents/info.plist', 'wb').write(info) 97 | 98 | 99 | if __name__ == '__main__': 100 | 101 | db = sqlite3.connect(docset_name + '/Contents/Resources/docSet.dsidx') 102 | cur = db.cursor() 103 | try: 104 | cur.execute('DROP TABLE searchIndex;') 105 | except: 106 | pass 107 | cur.execute('CREATE TABLE searchIndex(id INTEGER PRIMARY KEY, name TEXT, type TEXT, path TEXT);') 108 | cur.execute('CREATE UNIQUE INDEX anchor ON searchIndex (name, type, path);') 109 | 110 | # start 111 | add_docs() 112 | add_infoplist() 113 | 114 | # commit and close db 115 | db.commit() 116 | db.close() -------------------------------------------------------------------------------- /screenshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iamaziz/git-dash/5094f4e82fe61984265391c916d545705cb740c9/screenshot.png --------------------------------------------------------------------------------