Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Autogenerated HTML docs for v1.8.4-242-gbb80ee

  • Loading branch information...
commit 8eac268d5824abada1efa8990ea211f476ca942b 1 parent 91e3395
@gitster authored
View
59 RelNotes/1.8.5.txt
@@ -63,6 +63,43 @@ Foreign interfaces, subsystems and ports.
UI, Workflows & Features
+ * Magic pathspecs like ":(icase)makefile" that matches both
+ Makefile and makefile can be used in more places.
+
+ * The "http.*" variables can now be specified per URL that the
+ configuration applies. For example,
+
+ [http]
+ sslVerify = true
+ [http "https://weak.example.com/"]
+ sslVerify = false
+
+ would flip http.sslVerify off only when talking to that specified
+ site.
+
+ * "git mv A B" when moving a submodule A has been taught to
+ relocate its working tree and to adjust the paths in the
+ .gitmodules file.
+
+ * "git blame" can now take more than one -L option to discover the
+ origin of multiple blocks of the lines.
+
+ * The http transport clients can optionally ask to save cookies
+ with http.savecookies configuration variable.
+
+ * "git push" learned a more fine grained control over a blunt
+ "--force" when requesting a non-fast-forward update with the
+ "--force-with-lease=<refname>:<expected object name>" option.
+
+ * "git diff --diff-filter=<classes of changes>" can now take
+ lowercase letters (e.g. "--diff-filter=d") to mean "show
+ everything but these classes". "git diff-files -q" is now a
+ deprecated synonym for "git diff-files --diff-filter=d".
+
+ * "git fetch" (hence "git pull" as well) learned to check
+ "fetch.prune" and "remote.*.prune" configuration variables and
+ to behave as if the "--prune" command line option was given.
+
* "git check-ignore -z" applied the NUL termination to both its input
(with --stdin) and its output, but "git check-attr -z" ignored the
option on the output side. Make both honor -z on the input and
@@ -107,6 +144,28 @@ Unless otherwise noted, all the fixes since v1.8.4 in the maintenance
track are contained in this release (see release notes to them for
details).
+ * The mailmap support code read past the allocated buffer when the
+ mailmap file ended with an incomplete line.
+ (merge f972a16 jk/mailmap-incomplete-line later to maint).
+
+ * We used to send a large request to read(2)/write(2) as a single
+ system call, which was bad from the latency point of view when
+ the operation needs to be killed, and also triggered an error on
+ broken 64-bit systems that refuse to take more than 2GB read or
+ write in one go.
+ (merge a487916 sp/clip-read-write-to-8mb later to maint).
+
+ * "git fetch" that auto-followed tags incorrectly reused the
+ connection with Git-aware transport helper (like the sample "ext::"
+ helper shipped with Git).
+ (merge 0f73f8b jc/transport-do-not-use-connect-twice-in-fetch later to maint).
+
+ * "git log --full-diff -- <pathspec>" showed a huge diff for paths
+ outside the given <pathspec> for each commit, instead of showing
+ the change relative to the parent of the commit. "git reflog -p"
+ had a similar problem.
+ (merge 838f9a1 tr/log-full-diff-keep-true-parents later to maint).
+
* Setting submodule.*.path configuration variable to true (without
giving "= value") caused Git to segfault.
(merge 4b05440 jl/some-submodule-config-are-not-boolean later to maint).
View
10 blame-options.txt
@@ -11,12 +11,12 @@
-L <start>,<end>::
-L :<regex>::
- Annotate only the given line range. <start> and <end> are optional.
- ``-L <start>'' or ``-L <start>,'' spans from <start> to end of file.
- ``-L ,<end>'' spans from start of file to <end>.
+ Annotate only the given line range. May be specified multiple times.
+ Overlapping ranges are allowed.
++
+<start> and <end> are optional. ``-L <start>'' or ``-L <start>,'' spans from
+<start> to end of file. ``-L ,<end>'' spans from start of file to <end>.
+
-<start> and <end> can take one of these forms:
-
include::line-range-format.txt[]
-l::
View
61 config.txt
@@ -1061,6 +1061,10 @@ fetch.unpackLimit::
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
+fetch.prune::
+ If true, fetch will automatically behave as if the `--prune`
+ option was given on the command line. See also `remote.<name>.prune`.
+
format.attach::
Enable multipart/mixed attachments as the default for
'format-patch'. The value can also be a double quoted string
@@ -1445,7 +1449,11 @@ http.cookiefile::
of the file to read cookies from should be plain HTTP headers or
the Netscape/Mozilla cookie file format (see linkgit:curl[1]).
NOTE that the file specified with http.cookiefile is only used as
- input. No cookies will be stored in the file.
+ input unless http.saveCookies is set.
+
+http.savecookies::
+ If set, store cookies received during requests to the file specified by
+ http.cookiefile. Has no effect if http.cookiefile is unset.
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
@@ -1525,6 +1533,51 @@ http.useragent::
of common USER_AGENT strings (but not including those like git/1.7.1).
Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.
+http.<url>.*::
+ Any of the http.* options above can be applied selectively to some urls.
+ For a config key to match a URL, each element of the config key is
+ compared to that of the URL, in the following order:
++
+--
+. Scheme (e.g., `https` in `https://example.com/`). This field
+ must match exactly between the config key and the URL.
+
+. Host/domain name (e.g., `example.com` in `https://example.com/`).
+ This field must match exactly between the config key and the URL.
+
+. Port number (e.g., `8080` in `http://example.com:8080/`).
+ This field must match exactly between the config key and the URL.
+ Omitted port numbers are automatically converted to the correct
+ default for the scheme before matching.
+
+. Path (e.g., `repo.git` in `https://example.com/repo.git`). The
+ path field of the config key must match the path field of the URL
+ either exactly or as a prefix of slash-delimited path elements. This means
+ a config key with path `foo/` matches URL path `foo/bar`. A prefix can only
+ match on a slash (`/`) boundary. Longer matches take precedence (so a config
+ key with path `foo/bar` is a better match to URL path `foo/bar` than a config
+ key with just path `foo/`).
+
+. User name (e.g., `user` in `https://user@example.com/repo.git`). If
+ the config key has a user name it must match the user name in the
+ URL exactly. If the config key does not have a user name, that
+ config key will match a URL with any user name (including none),
+ but at a lower precedence than a config key with a user name.
+--
++
+The list above is ordered by decreasing precedence; a URL that matches
+a config key's path is preferred to one that matches its user name. For example,
+if the URL is `https://user@example.com/foo/bar` a config key match of
+`https://example.com/foo` will be preferred over a config key match of
+`https://user@example.com`.
++
+All URLs are normalized before attempting any matching (the password part,
+if embedded in the URL, is always ignored for matching purposes) so that
+equivalent urls that are simply spelled differently will match properly.
+Environment variable settings always override any matches. The urls that are
+matched against are those given directly to Git commands. This means any URLs
+visited as a result of a redirection do not participate in matching.
+
i18n.commitEncoding::
Character encoding the commit messages are stored in; Git itself
does not care per se, but this information is necessary e.g. when
@@ -2024,6 +2077,12 @@ remote.<name>.vcs::
Setting this to a value <vcs> will cause Git to interact with
the remote with the git-remote-<vcs> helper.
+remote.<name>.prune::
+ When set to true, fetching from this remote by default will also
+ remove any remote-tracking branches which no longer exist on the
+ remote (as if the `--prune` option was give on the command line).
+ Overrides `fetch.prune` settings, if any.
+
remotes.<group>::
The list of remotes which are fetched by "git remote update
<group>". See linkgit:git-remote[1].
View
25 git-annotate.html
@@ -800,10 +800,11 @@ <h2 id="_options">OPTIONS</h2>
</dt>
<dd>
<p>
- Annotate only the given line range. &lt;start&gt; and &lt;end&gt; are optional.
- &#8220;-L &lt;start&gt;&#8221; or &#8220;-L &lt;start&gt;,&#8221; spans from &lt;start&gt; to end of file.
- &#8220;-L ,&lt;end&gt;&#8221; spans from start of file to &lt;end&gt;.
+ Annotate only the given line range. May be specified multiple times.
+ Overlapping ranges are allowed.
</p>
+<div class="paragraph"><p>&lt;start&gt; and &lt;end&gt; are optional. &#8220;-L &lt;start&gt;&#8221; or &#8220;-L &lt;start&gt;,&#8221; spans from
+&lt;start&gt; to end of file. &#8220;-L ,&lt;end&gt;&#8221; spans from start of file to &lt;end&gt;.</p></div>
<div class="paragraph"><p>&lt;start&gt; and &lt;end&gt; can take one of these forms:</p></div>
<div class="ulist"><ul>
<li>
@@ -818,7 +819,10 @@ <h2 id="_options">OPTIONS</h2>
/regex/
</p>
<div class="paragraph"><p>This form will use the first line matching the given
-POSIX regex. If &lt;end&gt; is a regex, it will search
+POSIX regex. If &lt;start&gt; is a regex, it will search from the end of
+the previous <code>-L</code> range, if any, otherwise from the start of file.
+If &lt;start&gt; is &#8220;^/regex/&#8221;, it will search from the start of file.
+If &lt;end&gt; is a regex, it will search
starting at the line given by &lt;start&gt;.</p></div>
</li>
<li>
@@ -828,15 +832,12 @@ <h2 id="_options">OPTIONS</h2>
<div class="paragraph"><p>This is only valid for &lt;end&gt; and will specify a number
of lines before or after the line given by &lt;start&gt;.</p></div>
</li>
-<li>
-<p>
-:regex
-</p>
-<div class="paragraph"><p>If the option&#8217;s argument is of the form :regex, it denotes the range
-from the first funcname line that matches &lt;regex&gt;, up to the next
-funcname line.</p></div>
-</li>
</ul></div>
+<div class="paragraph"><p>If &#8220;:&lt;regex&gt;&#8221; is given in place of &lt;start&gt; and &lt;end&gt;, it denotes the range
+from the first funcname line that matches &lt;regex&gt;, up to the next
+funcname line. &#8220;:&lt;regex&gt;&#8221; searches from the end of the previous <code>-L</code> range,
+if any, otherwise from the start of file.
+&#8220;^:&lt;regex&gt;&#8221; searches from the start of file.</p></div>
</dd>
<dt class="hdlist1">
-l
View
36 git-blame.html
@@ -747,7 +747,7 @@ <h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git blame</em> [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
- [-L n,m | -L :fn] [-S &lt;revs-file&gt;] [-M] [-C] [-C] [-C] [--since=&lt;date&gt;]
+ [-L &lt;range&gt;] [-S &lt;revs-file&gt;] [-M] [-C] [-C] [-C] [--since=&lt;date&gt;]
[--abbrev=&lt;n&gt;] [&lt;rev&gt; | --contents &lt;file&gt; | --reverse &lt;rev&gt;] [--] &lt;file&gt;</pre>
<div class="attribution">
</div></div>
@@ -758,7 +758,8 @@ <h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Annotates each line in the given file with information from the revision which
last modified the line. Optionally, start annotating from the given revision.</p></div>
-<div class="paragraph"><p>The command can also limit the range of lines annotated.</p></div>
+<div class="paragraph"><p>When specified one or more times, <code>-L</code> restricts annotation to the requested
+lines.</p></div>
<div class="paragraph"><p>The origin of lines is automatically followed across whole-file
renames (currently there is no option to turn the rename-following
off). To follow lines moved from one file to another, or to follow
@@ -818,10 +819,11 @@ <h2 id="_options">OPTIONS</h2>
</dt>
<dd>
<p>
- Annotate only the given line range. &lt;start&gt; and &lt;end&gt; are optional.
- &#8220;-L &lt;start&gt;&#8221; or &#8220;-L &lt;start&gt;,&#8221; spans from &lt;start&gt; to end of file.
- &#8220;-L ,&lt;end&gt;&#8221; spans from start of file to &lt;end&gt;.
+ Annotate only the given line range. May be specified multiple times.
+ Overlapping ranges are allowed.
</p>
+<div class="paragraph"><p>&lt;start&gt; and &lt;end&gt; are optional. &#8220;-L &lt;start&gt;&#8221; or &#8220;-L &lt;start&gt;,&#8221; spans from
+&lt;start&gt; to end of file. &#8220;-L ,&lt;end&gt;&#8221; spans from start of file to &lt;end&gt;.</p></div>
<div class="paragraph"><p>&lt;start&gt; and &lt;end&gt; can take one of these forms:</p></div>
<div class="ulist"><ul>
<li>
@@ -836,7 +838,10 @@ <h2 id="_options">OPTIONS</h2>
/regex/
</p>
<div class="paragraph"><p>This form will use the first line matching the given
-POSIX regex. If &lt;end&gt; is a regex, it will search
+POSIX regex. If &lt;start&gt; is a regex, it will search from the end of
+the previous <code>-L</code> range, if any, otherwise from the start of file.
+If &lt;start&gt; is &#8220;^/regex/&#8221;, it will search from the start of file.
+If &lt;end&gt; is a regex, it will search
starting at the line given by &lt;start&gt;.</p></div>
</li>
<li>
@@ -846,15 +851,12 @@ <h2 id="_options">OPTIONS</h2>
<div class="paragraph"><p>This is only valid for &lt;end&gt; and will specify a number
of lines before or after the line given by &lt;start&gt;.</p></div>
</li>
-<li>
-<p>
-:regex
-</p>
-<div class="paragraph"><p>If the option&#8217;s argument is of the form :regex, it denotes the range
-from the first funcname line that matches &lt;regex&gt;, up to the next
-funcname line.</p></div>
-</li>
</ul></div>
+<div class="paragraph"><p>If &#8220;:&lt;regex&gt;&#8221; is given in place of &lt;start&gt; and &lt;end&gt;, it denotes the range
+from the first funcname line that matches &lt;regex&gt;, up to the next
+funcname line. &#8220;:&lt;regex&gt;&#8221; searches from the end of the previous <code>-L</code> range,
+if any, otherwise from the start of file.
+&#8220;^:&lt;regex&gt;&#8221; searches from the start of file.</p></div>
</dd>
<dt class="hdlist1">
-l
@@ -1169,7 +1171,9 @@ <h2 id="_specifying_ranges">SPECIFYING RANGES</h2>
<div class="sectionbody">
<div class="paragraph"><p>Unlike <em>git blame</em> and <em>git annotate</em> in older versions of git, the extent
of the annotation can be limited to both line ranges and revision
-ranges. When you are interested in finding the origin for
+ranges. The <code>-L</code> option, which limits annotation to a range of lines, may be
+specified multiple times.</p></div>
+<div class="paragraph"><p>When you are interested in finding the origin for
lines 40-60 for file <code>foo</code>, you can use the <code>-L</code> option like so
(they mean the same thing&#8201;&#8212;&#8201;both ask for 21 lines starting at
line 40):</p></div>
@@ -1377,7 +1381,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
10 git-blame.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
- [-L n,m | -L :fn] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
+ [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>] [--] <file>
DESCRIPTION
@@ -18,7 +18,8 @@ DESCRIPTION
Annotates each line in the given file with information from the revision which
last modified the line. Optionally, start annotating from the given revision.
-The command can also limit the range of lines annotated.
+When specified one or more times, `-L` restricts annotation to the requested
+lines.
The origin of lines is automatically followed across whole-file
renames (currently there is no option to turn the rename-following
@@ -130,7 +131,10 @@ SPECIFYING RANGES
Unlike 'git blame' and 'git annotate' in older versions of git, the extent
of the annotation can be limited to both line ranges and revision
-ranges. When you are interested in finding the origin for
+ranges. The `-L` option, which limits annotation to a range of lines, may be
+specified multiple times.
+
+When you are interested in finding the origin for
lines 40-60 for file `foo`, you can use the `-L` option like so
(they mean the same thing -- both ask for 21 lines starting at
line 40):
View
20 git-cat-file.html
@@ -879,9 +879,9 @@ <h2 id="_output">OUTPUT</h2>
<h2 id="_batch_output">BATCH OUTPUT</h2>
<div class="sectionbody">
<div class="paragraph"><p>If <code>--batch</code> or <code>--batch-check</code> is given, <code>cat-file</code> will read objects
-from stdin, one per line, and print information about them.</p></div>
-<div class="paragraph"><p>Each line is considered as a whole object name, and is parsed as if
-given to <a href="git-rev-parse.html">git-rev-parse(1)</a>.</p></div>
+from stdin, one per line, and print information about them. By default,
+the whole line is considered as an object, as if it were fed to
+<a href="git-rev-parse.html">git-rev-parse(1)</a>.</p></div>
<div class="paragraph"><p>You can specify the information shown for each object by using a custom
<code>&lt;format&gt;</code>. The <code>&lt;format&gt;</code> is copied literally to stdout for each
object, with placeholders of the form <code>%(atom)</code> expanded, followed by a
@@ -921,6 +921,18 @@ <h2 id="_batch_output">BATCH OUTPUT</h2>
note about on-disk sizes in the <code>CAVEATS</code> section below.
</p>
</dd>
+<dt class="hdlist1">
+<code>rest</code>
+</dt>
+<dd>
+<p>
+ If this atom is used in the output string, input lines are split
+ at the first whitespace boundary. All characters before that
+ whitespace are considered to be the object name; characters
+ after that first run of whitespace (i.e., the "rest" of the
+ line) are output in place of the <code>%(rest)</code> atom.
+</p>
+</dd>
</dl></div>
<div class="paragraph"><p>If no format is specified, the default format is <code>%(objectname)
%(objecttype) %(objectsize)</code>.</p></div>
@@ -969,7 +981,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
14 git-cat-file.txt
@@ -86,10 +86,9 @@ BATCH OUTPUT
------------
If `--batch` or `--batch-check` is given, `cat-file` will read objects
-from stdin, one per line, and print information about them.
-
-Each line is considered as a whole object name, and is parsed as if
-given to linkgit:git-rev-parse[1].
+from stdin, one per line, and print information about them. By default,
+the whole line is considered as an object, as if it were fed to
+linkgit:git-rev-parse[1].
You can specify the information shown for each object by using a custom
`<format>`. The `<format>` is copied literally to stdout for each
@@ -110,6 +109,13 @@ newline. The available atoms are:
The size, in bytes, that the object takes up on disk. See the
note about on-disk sizes in the `CAVEATS` section below.
+`rest`::
+ If this atom is used in the output string, input lines are split
+ at the first whitespace boundary. All characters before that
+ whitespace are considered to be the object name; characters
+ after that first run of whitespace (i.e., the "rest" of the
+ line) are output in place of the `%(rest)` atom.
+
If no format is specified, the default format is `%(objectname)
%(objecttype) %(objectsize)`.
View
134 git-config.html
@@ -752,6 +752,7 @@ <h2 id="_synopsis">SYNOPSIS</h2>
<em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] --get name [value_regex]
<em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] --get-all name [value_regex]
<em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] --get-regexp name_regex [value_regex]
+<em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] --get-urlmatch name URL
<em>git config</em> [&lt;file-option&gt;] --unset name [value_regex]
<em>git config</em> [&lt;file-option&gt;] --unset-all name [value_regex]
<em>git config</em> [&lt;file-option&gt;] --rename-section old_name new_name
@@ -887,6 +888,19 @@ <h2 id="_options">OPTIONS</h2>
</p>
</dd>
<dt class="hdlist1">
+--get-urlmatch name URL
+</dt>
+<dd>
+<p>
+ When given a two-part name section.key, the value for
+ section.&lt;url&gt;.key whose &lt;url&gt; part matches the best to the
+ given URL is returned (if no such key exists, the value for
+ section.key is used as a fallback). When given just the
+ section as name, do so for all the keys in the section and
+ list them.
+</p>
+</dd>
+<dt class="hdlist1">
--global
</dt>
<dd>
@@ -1219,6 +1233,15 @@ <h2 id="EXAMPLES">EXAMPLES</h2>
gitproxy=proxy-command for kernel.org
gitproxy=default-proxy ; for all the rest</code></pre>
</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><code>; HTTP
+[http]
+ sslVerify
+[http "https://weak.example.com"]
+ sslVerify = false
+ cookieFile = /tmp/cookie.txt</code></pre>
+</div></div>
<div class="paragraph"><p>you can set the filemode to true with</p></div>
<div class="listingblock">
<div class="content">
@@ -1290,6 +1313,18 @@ <h2 id="EXAMPLES">EXAMPLES</h2>
RESET=$(git config --get-color "" "reset")
echo "${WS}your whitespace color or blue reverse${RESET}"</code></pre>
</div></div>
+<div class="paragraph"><p>For URLs in <code>https://weak.example.com</code>, <code>http.sslVerify</code> is set to
+false, while it is set to <code>true</code> for all others:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code>% git config --bool --get-urlmatch http.sslverify https://good.example.com
+true
+% git config --bool --get-urlmatch http.sslverify https://weak.example.com
+false
+% git config --get-urlmatch http https://weak.example.com
+http.cookiefile /tmp/cookie.txt
+http.sslverify false</code></pre>
+</div></div>
</div>
</div>
<div class="sect1">
@@ -3437,6 +3472,15 @@ <h3 id="_variables">Variables</h3>
</p>
</dd>
<dt class="hdlist1">
+fetch.prune
+</dt>
+<dd>
+<p>
+ If true, fetch will automatically behave as if the <code>--prune</code>
+ option was given on the command line. See also <code>remote.&lt;name&gt;.prune</code>.
+</p>
+</dd>
+<dt class="hdlist1">
format.attach
</dt>
<dd>
@@ -4168,7 +4212,16 @@ <h3 id="_variables">Variables</h3>
of the file to read cookies from should be plain HTTP headers or
the Netscape/Mozilla cookie file format (see <a href="curl.html">curl(1)</a>).
NOTE that the file specified with http.cookiefile is only used as
- input. No cookies will be stored in the file.
+ input unless http.saveCookies is set.
+</p>
+</dd>
+<dt class="hdlist1">
+http.savecookies
+</dt>
+<dd>
+<p>
+ If set, store cookies received during requests to the file specified by
+ http.cookiefile. Has no effect if http.cookiefile is unset.
</p>
</dd>
<dt class="hdlist1">
@@ -4315,6 +4368,72 @@ <h3 id="_variables">Variables</h3>
</p>
</dd>
<dt class="hdlist1">
+http.&lt;url&gt;.*
+</dt>
+<dd>
+<p>
+ Any of the http.* options above can be applied selectively to some urls.
+ For a config key to match a URL, each element of the config key is
+ compared to that of the URL, in the following order:
+</p>
+<div class="openblock">
+<div class="content">
+<div class="olist arabic"><ol class="arabic">
+<li>
+<p>
+Scheme (e.g., <code>https</code> in <code>https://example.com/</code>). This field
+ must match exactly between the config key and the URL.
+</p>
+</li>
+<li>
+<p>
+Host/domain name (e.g., <code>example.com</code> in <code>https://example.com/</code>).
+ This field must match exactly between the config key and the URL.
+</p>
+</li>
+<li>
+<p>
+Port number (e.g., <code>8080</code> in <code>http://example.com:8080/</code>).
+ This field must match exactly between the config key and the URL.
+ Omitted port numbers are automatically converted to the correct
+ default for the scheme before matching.
+</p>
+</li>
+<li>
+<p>
+Path (e.g., <code>repo.git</code> in <code>https://example.com/repo.git</code>). The
+ path field of the config key must match the path field of the URL
+ either exactly or as a prefix of slash-delimited path elements. This means
+ a config key with path <code>foo/</code> matches URL path <code>foo/bar</code>. A prefix can only
+ match on a slash (<code>/</code>) boundary. Longer matches take precedence (so a config
+ key with path <code>foo/bar</code> is a better match to URL path <code>foo/bar</code> than a config
+ key with just path <code>foo/</code>).
+</p>
+</li>
+<li>
+<p>
+User name (e.g., <code>user</code> in <code>https://user@example.com/repo.git</code>). If
+ the config key has a user name it must match the user name in the
+ URL exactly. If the config key does not have a user name, that
+ config key will match a URL with any user name (including none),
+ but at a lower precedence than a config key with a user name.
+</p>
+</li>
+</ol></div>
+</div></div>
+<div class="paragraph"><p>The list above is ordered by decreasing precedence; a URL that matches
+a config key&#8217;s path is preferred to one that matches its user name. For example,
+if the URL is <code>https://user@example.com/foo/bar</code> a config key match of
+<code>https://example.com/foo</code> will be preferred over a config key match of
+<code>https://user@example.com</code>.</p></div>
+<div class="paragraph"><p>All URLs are normalized before attempting any matching (the password part,
+if embedded in the URL, is always ignored for matching purposes) so that
+equivalent urls that are simply spelled differently will match properly.
+Environment variable settings always override any matches. The urls that are
+matched against are those given directly to Git commands. This means any URLs
+visited as a result of a redirection do not participate in matching.</p></div>
+</dd>
+<dt class="hdlist1">
i18n.commitEncoding
</dt>
<dd>
@@ -5398,6 +5517,17 @@ <h3 id="_variables">Variables</h3>
</p>
</dd>
<dt class="hdlist1">
+remote.&lt;name&gt;.prune
+</dt>
+<dd>
+<p>
+ When set to true, fetching from this remote by default will also
+ remove any remote-tracking branches which no longer exist on the
+ remote (as if the <code>--prune</code> option was give on the command line).
+ Overrides <code>fetch.prune</code> settings, if any.
+</p>
+</dd>
+<dt class="hdlist1">
remotes.&lt;group&gt;
</dt>
<dd>
@@ -5875,7 +6005,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
29 git-config.txt
@@ -15,6 +15,7 @@ SYNOPSIS
'git config' [<file-option>] [type] [-z|--null] --get name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
+'git config' [<file-option>] [type] [-z|--null] --get-urlmatch name URL
'git config' [<file-option>] --unset name [value_regex]
'git config' [<file-option>] --unset-all name [value_regex]
'git config' [<file-option>] --rename-section old_name new_name
@@ -95,6 +96,14 @@ OPTIONS
in which section and variable names are lowercased, but subsection
names are not.
+--get-urlmatch name URL::
+ When given a two-part name section.key, the value for
+ section.<url>.key whose <url> part matches the best to the
+ given URL is returned (if no such key exists, the value for
+ section.key is used as a fallback). When given just the
+ section as name, do so for all the keys in the section and
+ list them.
+
--global::
For writing options: write to global `~/.gitconfig` file
rather than the repository `.git/config`, write to
@@ -295,6 +304,13 @@ Given a .git/config like this:
gitproxy=proxy-command for kernel.org
gitproxy=default-proxy ; for all the rest
+ ; HTTP
+ [http]
+ sslVerify
+ [http "https://weak.example.com"]
+ sslVerify = false
+ cookieFile = /tmp/cookie.txt
+
you can set the filemode to true with
------------
@@ -380,6 +396,19 @@ RESET=$(git config --get-color "" "reset")
echo "${WS}your whitespace color or blue reverse${RESET}"
------------
+For URLs in `https://weak.example.com`, `http.sslVerify` is set to
+false, while it is set to `true` for all others:
+
+------------
+% git config --bool --get-urlmatch http.sslverify https://good.example.com
+true
+% git config --bool --get-urlmatch http.sslverify https://weak.example.com
+false
+% git config --get-urlmatch http https://weak.example.com
+http.cookiefile /tmp/cookie.txt
+http.sslverify false
+------------
+
include::config.txt[]
GIT
View
11 git-fetch-pack.html
@@ -885,6 +885,15 @@ <h2 id="_options">OPTIONS</h2>
</p>
</dd>
<dt class="hdlist1">
+--check-self-contained-and-connected
+</dt>
+<dd>
+<p>
+ Output "connectivity-ok" if the received pack is
+ self-contained and connected.
+</p>
+</dd>
+<dt class="hdlist1">
-v
</dt>
<dd>
@@ -933,7 +942,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
4 git-fetch-pack.txt
@@ -90,6 +90,10 @@ be in a separate packet, and the list must end with a flush packet.
--no-progress::
Do not show the progress.
+--check-self-contained-and-connected::
+ Output "connectivity-ok" if the received pack is
+ self-contained and connected.
+
-v::
Run verbosely.
View
25 git-log.html
@@ -835,7 +835,10 @@ <h2 id="_options">OPTIONS</h2>
</p>
</dd>
<dt class="hdlist1">
--L &lt;start&gt;,&lt;end&gt;:&lt;file&gt;, -L :&lt;regex&gt;:&lt;file&gt;
+-L &lt;start&gt;,&lt;end&gt;:&lt;file&gt;
+</dt>
+<dt class="hdlist1">
+-L :&lt;regex&gt;:&lt;file&gt;
</dt>
<dd>
<p>
@@ -860,7 +863,10 @@ <h2 id="_options">OPTIONS</h2>
/regex/
</p>
<div class="paragraph"><p>This form will use the first line matching the given
-POSIX regex. If &lt;end&gt; is a regex, it will search
+POSIX regex. If &lt;start&gt; is a regex, it will search from the end of
+the previous <code>-L</code> range, if any, otherwise from the start of file.
+If &lt;start&gt; is &#8220;^/regex/&#8221;, it will search from the start of file.
+If &lt;end&gt; is a regex, it will search
starting at the line given by &lt;start&gt;.</p></div>
</li>
<li>
@@ -870,15 +876,12 @@ <h2 id="_options">OPTIONS</h2>
<div class="paragraph"><p>This is only valid for &lt;end&gt; and will specify a number
of lines before or after the line given by &lt;start&gt;.</p></div>
</li>
-<li>
-<p>
-:regex
-</p>
-<div class="paragraph"><p>If the option&#8217;s argument is of the form :regex, it denotes the range
-from the first funcname line that matches &lt;regex&gt;, up to the next
-funcname line.</p></div>
-</li>
</ul></div>
+<div class="paragraph"><p>If &#8220;:&lt;regex&gt;&#8221; is given in place of &lt;start&gt; and &lt;end&gt;, it denotes the range
+from the first funcname line that matches &lt;regex&gt;, up to the next
+funcname line. &#8220;:&lt;regex&gt;&#8221; searches from the end of the previous <code>-L</code> range,
+if any, otherwise from the start of file.
+&#8220;^:&lt;regex&gt;&#8221; searches from the start of file.</p></div>
</dd>
<dt class="hdlist1">
&lt;revision range&gt;
@@ -3931,7 +3934,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
5 git-log.txt
@@ -62,7 +62,8 @@ produced by --stat etc.
Note that only message is considered, if also a diff is shown
its size is not included.
--L <start>,<end>:<file>, -L :<regex>:<file>::
+-L <start>,<end>:<file>::
+-L :<regex>:<file>::
Trace the evolution of the line range given by "<start>,<end>"
(or the funcname regex <regex>) within the <file>. You may
@@ -71,8 +72,6 @@ produced by --stat etc.
give zero or one positive revision arguments.
You can specify this option more than once.
+
-<start> and <end> can take one of these forms:
-
include::line-range-format.txt[]
<revision range>::
View
14 git-mv.html
@@ -754,7 +754,7 @@ <h2 id="_synopsis">SYNOPSIS</h2>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>This script is used to move or rename a file, directory or symlink.</p></div>
+<div class="paragraph"><p>Move or rename a file, directory or symlink.</p></div>
<div class="literalblock">
<div class="content">
<pre><code>git mv [-v] [-f] [-n] [-k] &lt;source&gt; &lt;destination&gt;
@@ -820,6 +820,16 @@ <h2 id="_options">OPTIONS</h2>
</div>
</div>
<div class="sect1">
+<h2 id="_submodules">SUBMODULES</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Moving a submodule using a gitfile (which means they were cloned
+with a Git version 1.7.8 or newer) will update the gitfile and
+core.worktree setting to make the submodule work in the new location.
+It also will attempt to update the submodule.&lt;name&gt;.path setting in
+the <a href="gitmodules.html">gitmodules(5)</a> file and stage that file (unless -n is used).</p></div>
+</div>
+</div>
+<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@@ -829,7 +839,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
10 git-mv.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-This script is used to move or rename a file, directory or symlink.
+Move or rename a file, directory or symlink.
git mv [-v] [-f] [-n] [-k] <source> <destination>
git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
@@ -44,6 +44,14 @@ OPTIONS
--verbose::
Report the names of files as they are moved.
+SUBMODULES
+----------
+Moving a submodule using a gitfile (which means they were cloned
+with a Git version 1.7.8 or newer) will update the gitfile and
+core.worktree setting to make the submodule work in the new location.
+It also will attempt to update the submodule.<name>.path setting in
+the linkgit:gitmodules[5] file and stage that file (unless -n is used).
+
GIT
---
Part of the linkgit:git[1] suite
View
78 git-push.html
@@ -748,6 +748,7 @@ <h2 id="_synopsis">SYNOPSIS</h2>
<div class="verseblock">
<pre class="content"><em>git push</em> [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=&lt;git-receive-pack&gt;]
[--repo=&lt;repository&gt;] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream]
+ [--force-with-lease[=&lt;refname&gt;[:&lt;expect&gt;]]]
[--no-verify] [&lt;repository&gt; [&lt;refspec&gt;&#8230;]]</pre>
<div class="attribution">
</div></div>
@@ -923,6 +924,57 @@ <h2 id="_options_a_id_options_a">OPTIONS<a id="OPTIONS"></a></h2>
</p>
</dd>
<dt class="hdlist1">
+--[no-]force-with-lease
+</dt>
+<dt class="hdlist1">
+--force-with-lease=&lt;refname&gt;
+</dt>
+<dt class="hdlist1">
+--force-with-lease=&lt;refname&gt;:&lt;expect&gt;
+</dt>
+<dd>
+<p>
+ Usually, "git push" refuses to update a remote ref that is
+ not an ancestor of the local ref used to overwrite it.
+</p>
+<div class="paragraph"><p>This option bypasses the check, but instead requires that the
+current value of the ref to be the expected value. "git push"
+fails otherwise.</p></div>
+<div class="paragraph"><p>Imagine that you have to rebase what you have already published.
+You will have to bypass the "must fast-forward" rule in order to
+replace the history you originally published with the rebased history.
+If somebody else built on top of your original history while you are
+rebasing, the tip of the branch at the remote may advance with her
+commit, and blindly pushing with <code>--force</code> will lose her work.</p></div>
+<div class="paragraph"><p>This option allows you to say that you expect the history you are
+updating is what you rebased and want to replace. If the remote ref
+still points at the commit you specified, you can be sure that no
+other people did anything to the ref (it is like taking a "lease" on
+the ref without explicitly locking it, and you update the ref while
+making sure that your earlier "lease" is still valid).</p></div>
+<div class="paragraph"><p><code>--force-with-lease</code> alone, without specifying the details, will protect
+all remote refs that are going to be updated by requiring their
+current value to be the same as the remote-tracking branch we have
+for them, unless specified with a <code>--force-with-lease=&lt;refname&gt;:&lt;expect&gt;</code>
+option that explicitly states what the expected value is.</p></div>
+<div class="paragraph"><p><code>--force-with-lease=&lt;refname&gt;</code>, without specifying the expected value, will
+protect the named ref (alone), if it is going to be updated, by
+requiring its current value to be the same as the remote-tracking
+branch we have for it.</p></div>
+<div class="paragraph"><p><code>--force-with-lease=&lt;refname&gt;:&lt;expect&gt;</code> will protect the named ref (alone),
+if it is going to be updated, by requiring its current value to be
+the same as the specified value &lt;expect&gt; (which is allowed to be
+different from the remote-tracking branch we have for the refname,
+or we do not even have to have such a remote-tracking branch when
+this form is used).</p></div>
+<div class="paragraph"><p>Note that all forms other than <code>--force-with-lease=&lt;refname&gt;:&lt;expect&gt;</code>
+that specifies the expected current value of the ref explicitly are
+still experimental and their semantics may change as we gain experience
+with this feature.</p></div>
+<div class="paragraph"><p>"--no-force-with-lease" will cancel all the previous --force-with-lease on the
+command line.</p></div>
+</dd>
+<dt class="hdlist1">
-f
</dt>
<dt class="hdlist1">
@@ -932,18 +984,20 @@ <h2 id="_options_a_id_options_a">OPTIONS<a id="OPTIONS"></a></h2>
<p>
Usually, the command refuses to update a remote ref that is
not an ancestor of the local ref used to overwrite it.
- This flag disables the check. This can cause the
- remote repository to lose commits; use it with care.
- Note that <code>--force</code> applies to all the refs that are pushed,
- hence using it with <code>push.default</code> set to <code>matching</code> or with
- multiple push destinations configured with <code>remote.*.push</code>
- may overwrite refs other than the current branch (including
- local refs that are strictly behind their remote counterpart).
- To force a push to only one branch, use a <code>+</code> in front of the
- refspec to push (e.g <code>git push origin +master</code> to force a push
- to the <code>master</code> branch). See the <code>&lt;refspec&gt;...</code> section above
- for details.
+ Also, when <code>--force-with-lease</code> option is used, the command refuses
+ to update a remote ref whose current value does not match
+ what is expected.
</p>
+<div class="paragraph"><p>This flag disables these checks, and can cause the remote repository
+to lose commits; use it with care.</p></div>
+<div class="paragraph"><p>Note that <code>--force</code> applies to all the refs that are pushed, hence
+using it with <code>push.default</code> set to <code>matching</code> or with multiple push
+destinations configured with <code>remote.*.push</code> may overwrite refs
+other than the current branch (including local refs that are
+strictly behind their remote counterpart). To force a push to only
+one branch, use a <code>+</code> in front of the refspec to push (e.g <code>git push
+origin +master</code> to force a push to the <code>master</code> branch). See the
+<code>&lt;refspec&gt;...</code> section above for details.</p></div>
</dd>
<dt class="hdlist1">
--repo=&lt;repository&gt;
@@ -1668,7 +1722,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
77 git-push.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream]
+ [--force-with-lease[=<refname>[:<expect>]]]
[--no-verify] [<repository> [<refspec>...]]
DESCRIPTION
@@ -130,21 +131,75 @@ already exists on the remote side.
repository over ssh, and you do not have the program in
a directory on the default $PATH.
+--[no-]force-with-lease::
+--force-with-lease=<refname>::
+--force-with-lease=<refname>:<expect>::
+ Usually, "git push" refuses to update a remote ref that is
+ not an ancestor of the local ref used to overwrite it.
++
+This option bypasses the check, but instead requires that the
+current value of the ref to be the expected value. "git push"
+fails otherwise.
++
+Imagine that you have to rebase what you have already published.
+You will have to bypass the "must fast-forward" rule in order to
+replace the history you originally published with the rebased history.
+If somebody else built on top of your original history while you are
+rebasing, the tip of the branch at the remote may advance with her
+commit, and blindly pushing with `--force` will lose her work.
++
+This option allows you to say that you expect the history you are
+updating is what you rebased and want to replace. If the remote ref
+still points at the commit you specified, you can be sure that no
+other people did anything to the ref (it is like taking a "lease" on
+the ref without explicitly locking it, and you update the ref while
+making sure that your earlier "lease" is still valid).
++
+`--force-with-lease` alone, without specifying the details, will protect
+all remote refs that are going to be updated by requiring their
+current value to be the same as the remote-tracking branch we have
+for them, unless specified with a `--force-with-lease=<refname>:<expect>`
+option that explicitly states what the expected value is.
++
+`--force-with-lease=<refname>`, without specifying the expected value, will
+protect the named ref (alone), if it is going to be updated, by
+requiring its current value to be the same as the remote-tracking
+branch we have for it.
++
+`--force-with-lease=<refname>:<expect>` will protect the named ref (alone),
+if it is going to be updated, by requiring its current value to be
+the same as the specified value <expect> (which is allowed to be
+different from the remote-tracking branch we have for the refname,
+or we do not even have to have such a remote-tracking branch when
+this form is used).
++
+Note that all forms other than `--force-with-lease=<refname>:<expect>`
+that specifies the expected current value of the ref explicitly are
+still experimental and their semantics may change as we gain experience
+with this feature.
++
+"--no-force-with-lease" will cancel all the previous --force-with-lease on the
+command line.
+
-f::
--force::
Usually, the command refuses to update a remote ref that is
not an ancestor of the local ref used to overwrite it.
- This flag disables the check. This can cause the
- remote repository to lose commits; use it with care.
- Note that `--force` applies to all the refs that are pushed,
- hence using it with `push.default` set to `matching` or with
- multiple push destinations configured with `remote.*.push`
- may overwrite refs other than the current branch (including
- local refs that are strictly behind their remote counterpart).
- To force a push to only one branch, use a `+` in front of the
- refspec to push (e.g `git push origin +master` to force a push
- to the `master` branch). See the `<refspec>...` section above
- for details.
+ Also, when `--force-with-lease` option is used, the command refuses
+ to update a remote ref whose current value does not match
+ what is expected.
++
+This flag disables these checks, and can cause the remote repository
+to lose commits; use it with care.
++
+Note that `--force` applies to all the refs that are pushed, hence
+using it with `push.default` set to `matching` or with multiple push
+destinations configured with `remote.*.push` may overwrite refs
+other than the current branch (including local refs that are
+strictly behind their remote counterpart). To force a push to only
+one branch, use a `+` in front of the refspec to push (e.g `git push
+origin +master` to force a push to the `master` branch). See the
+`<refspec>...` section above for details.
--repo=<repository>::
This option is only relevant if no <repository> argument is
View
14 git-rm.html
@@ -922,14 +922,19 @@ <h3 id="_other_ways">Other ways</h3>
<pre><code>git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached</code></pre>
</div></div>
</div>
-<div class="sect2">
-<h3 id="_submodules">Submodules</h3>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_submodules">SUBMODULES</h2>
+<div class="sectionbody">
<div class="paragraph"><p>Only submodules using a gitfile (which means they were cloned
with a Git version 1.7.8 or newer) will be removed from the work
tree, as their repository lives inside the .git directory of the
superproject. If a submodule (or one of those nested inside it)
still uses a .git directory, <code>git rm</code> will fail - no matter if forced
-or not - to protect the submodule&#8217;s history.</p></div>
+or not - to protect the submodule&#8217;s history. If it exists the
+submodule.&lt;name&gt; section in the <a href="gitmodules.html">gitmodules(5)</a> file will also
+be removed and that file will be staged (unless --cached or -n are used).</p></div>
<div class="paragraph"><p>A submodule is considered up-to-date when the HEAD is the same as
recorded in the index, no tracked files are modified and no untracked
files that aren&#8217;t ignored are present in the submodules work tree.
@@ -940,7 +945,6 @@ <h3 id="_submodules">Submodules</h3>
use <a href="git-submodule.html">git-submodule(1)</a> <code>deinit</code> instead.</p></div>
</div>
</div>
-</div>
<div class="sect1">
<h2 id="_examples">EXAMPLES</h2>
<div class="sectionbody">
@@ -986,7 +990,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
8 git-rm.txt
@@ -134,14 +134,16 @@ use the following command:
git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
----------------
-Submodules
-~~~~~~~~~~
+SUBMODULES
+----------
Only submodules using a gitfile (which means they were cloned
with a Git version 1.7.8 or newer) will be removed from the work
tree, as their repository lives inside the .git directory of the
superproject. If a submodule (or one of those nested inside it)
still uses a .git directory, `git rm` will fail - no matter if forced
-or not - to protect the submodule's history.
+or not - to protect the submodule's history. If it exists the
+submodule.<name> section in the linkgit:gitmodules[5] file will also
+be removed and that file will be staged (unless --cached or -n are used).
A submodule is considered up-to-date when the HEAD is the same as
recorded in the index, no tracked files are modified and no untracked
View
46 git.html
@@ -928,12 +928,25 @@ <h2 id="_options">OPTIONS</h2>
</dt>
<dd>
<p>
- Treat pathspecs literally, rather than as glob patterns. This is
- equivalent to setting the <code>GIT_LITERAL_PATHSPECS</code> environment
+ Treat pathspecs literally (i.e. no globbing, no pathspec magic).
+ This is equivalent to setting the <code>GIT_LITERAL_PATHSPECS</code> environment
variable to <code>1</code>.
</p>
</dd>
</dl></div>
+<div class="paragraph"><p>--glob-pathspecs:
+ Add "glob" magic to all pathspec. This is equivalent to setting
+ the <code>GIT_GLOB_PATHSPECS</code> environment variable to <code>1</code>. Disabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(literal)"</p></div>
+<div class="paragraph"><p>--noglob-pathspecs:
+ Add "literal" magic to all pathspec. This is equivalent to setting
+ the <code>GIT_NOGLOB_PATHSPECS</code> environment variable to <code>1</code>. Enabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(glob)"</p></div>
+<div class="paragraph"><p>--icase-pathspecs:
+ Add "icase" magic to all pathspec. This is equivalent to setting
+ the <code>GIT_ICASE_PATHSPECS</code> environment variable to <code>1</code>.</p></div>
</div>
</div>
<div class="sect1">
@@ -2665,6 +2678,33 @@ <h3 id="_other">other</h3>
<code>git ls-tree</code>, <code>--raw</code> diff output, etc).
</p>
</dd>
+<dt class="hdlist1">
+GIT_GLOB_PATHSPECS
+</dt>
+<dd>
+<p>
+ Setting this variable to <code>1</code> will cause Git to treat all
+ pathspecs as glob patterns (aka "glob" magic).
+</p>
+</dd>
+<dt class="hdlist1">
+GIT_NOGLOB_PATHSPECS
+</dt>
+<dd>
+<p>
+ Setting this variable to <code>1</code> will cause Git to treat all
+ pathspecs as literal (aka "literal" magic).
+</p>
+</dd>
+<dt class="hdlist1">
+GIT_ICASE_PATHSPECS
+</dt>
+<dd>
+<p>
+ Setting this variable to <code>1</code> will cause Git to treat all
+ pathspecs as case-insensitive.
+</p>
+</dd>
</dl></div>
</div>
</div>
@@ -2773,7 +2813,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-30 16:51:59 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
31 git.txt
@@ -457,10 +457,25 @@ help ...`.
linkgit:git-replace[1] for more information.
--literal-pathspecs::
- Treat pathspecs literally, rather than as glob patterns. This is
- equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
+ Treat pathspecs literally (i.e. no globbing, no pathspec magic).
+ This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
variable to `1`.
+--glob-pathspecs:
+ Add "glob" magic to all pathspec. This is equivalent to setting
+ the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(literal)"
+
+--noglob-pathspecs:
+ Add "literal" magic to all pathspec. This is equivalent to setting
+ the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(glob)"
+
+--icase-pathspecs:
+ Add "icase" magic to all pathspec. This is equivalent to setting
+ the `GIT_ICASE_PATHSPECS` environment variable to `1`.
GIT COMMANDS
------------
@@ -867,6 +882,18 @@ GIT_LITERAL_PATHSPECS::
literal paths to Git (e.g., paths previously given to you by
`git ls-tree`, `--raw` diff output, etc).
+GIT_GLOB_PATHSPECS::
+ Setting this variable to `1` will cause Git to treat all
+ pathspecs as glob patterns (aka "glob" magic).
+
+GIT_NOGLOB_PATHSPECS::
+ Setting this variable to `1` will cause Git to treat all
+ pathspecs as literal (aka "literal" magic).
+
+GIT_ICASE_PATHSPECS::
+ Setting this variable to `1` will cause Git to treat all
+ pathspecs as case-insensitive.
+
Discussion[[Discussion]]
------------------------
View
86 gitglossary.html
@@ -1299,10 +1299,88 @@ <h2 id="_description">DESCRIPTION</h2>
and a close parentheses <code>)</code>, and the remainder is the pattern to match
against the path.</p></div>
<div class="paragraph"><p>The "magic signature" consists of an ASCII symbol that is not
-alphanumeric. Currently only the slash <code>/</code> is recognized as a
-"magic signature": it makes the pattern match from the root of
-the working tree, even when you are running the command from
-inside a subdirectory.</p></div>
+alphanumeric.</p></div>
+<div class="openblock">
+<div class="content">
+<div class="dlist"><dl>
+<dt class="hdlist1">
+top <code>/</code>
+</dt>
+<dd>
+<p>
+ The magic word <code>top</code> (mnemonic: <code>/</code>) makes the pattern match
+ from the root of the working tree, even when you are running
+ the command from inside a subdirectory.
+</p>
+</dd>
+<dt class="hdlist1">
+literal
+</dt>
+<dd>
+<p>
+ Wildcards in the pattern such as <code>*</code> or <code>?</code> are treated
+ as literal characters.
+</p>
+</dd>
+<dt class="hdlist1">
+icase
+</dt>
+<dd>
+<p>
+ Case insensitive match.
+</p>
+</dd>
+<dt class="hdlist1">
+glob
+</dt>
+<dd>
+<p>
+ Git treats the pattern as a shell glob suitable for
+ consumption by fnmatch(3) with the FNM_PATHNAME flag:
+ wildcards in the pattern will not match a / in the pathname.
+ For example, "Documentation/&#42;.html" matches
+ "Documentation/git.html" but not "Documentation/ppc/ppc.html"
+ or "tools/perf/Documentation/perf.html".
+</p>
+<div class="paragraph"><p>Two consecutive asterisks ("<code>**</code>") in patterns matched against
+full pathname may have special meaning:</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+A leading "<code>**</code>" followed by a slash means match in all
+ directories. For example, "<code>**/foo</code>" matches file or directory
+ "<code>foo</code>" anywhere, the same as pattern "<code>foo</code>". "**/foo/bar"
+ matches file or directory "<code>bar</code>" anywhere that is directly
+ under directory "<code>foo</code>".
+</p>
+</li>
+<li>
+<p>
+A trailing "/<strong>" matches everything inside. For example,
+ "abc/</strong>" matches all files inside directory "abc", relative
+ to the location of the <code>.gitignore</code> file, with infinite depth.
+</p>
+</li>
+<li>
+<p>
+A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, "<code>a/**/b</code>"
+ matches "<code>a/b</code>", "<code>a/x/b</code>", "<code>a/x/y/b</code>" and so on.
+</p>
+</li>
+<li>
+<p>
+Other consecutive asterisks are considered invalid.
+</p>
+<div class="paragraph"><p>Glob magic is incompatible with literal magic.</p></div>
+</li>
+</ul></div>
+</dd>
+</dl></div>
+</div></div>
+<div class="paragraph"><p>Currently only the slash <code>/</code> is recognized as the "magic signature",
+but it is envisioned that we will support more types of magic in later
+versions of Git.</p></div>
<div class="paragraph"><p>A pathspec with only a colon means "there is no pathspec". This form
should not be combined with other pathspec.</p></div>
</dd>
View
21 gitremote-helpers.html
@@ -902,6 +902,15 @@ <h4 id="_capabilities_for_fetching">Capabilities for Fetching</h4>
</p>
<div class="paragraph"><p>Supported commands: <em>list</em>, <em>import</em>.</p></div>
</dd>
+<dt class="hdlist1">
+<em>check-connectivity</em>
+</dt>
+<dd>
+<p>
+ Can guarantee that when a clone is requested, the received
+ pack is self contained and is connected.
+</p>
+</dd>
</dl></div>
<div class="paragraph"><p>If a helper advertises <em>connect</em>, Git will use it if possible and
fall back to another capability if the helper requests so when
@@ -1078,6 +1087,8 @@ <h2 id="_commands">COMMANDS</h2>
<div class="paragraph"><p>Optionally may output a <em>lock &lt;file&gt;</em> line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
suitably updated.</p></div>
+<div class="paragraph"><p>If option <em>check-connectivity</em> is requested, the helper must output
+<em>connectivity-ok</em> if the clone is self-contained and connected.</p></div>
<div class="paragraph"><p>Supported if the helper has the "fetch" capability.</p></div>
</dd>
<dt class="hdlist1">
@@ -1268,6 +1279,14 @@ <h2 id="_options">OPTIONS</h2>
connect request occurs.
</p>
</dd>
+<dt class="hdlist1">
+<em>option check-connectivity</em> {<em>true</em>|<em>false</em>}
+</dt>
+<dd>
+<p>
+ Request the helper to check connectivity of a clone.
+</p>
+</dd>
</dl></div>
</div>
</div>
@@ -1288,7 +1307,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
10 gitremote-helpers.txt
@@ -143,6 +143,10 @@ Supported commands: 'list', 'fetch'.
+
Supported commands: 'list', 'import'.
+'check-connectivity'::
+ Can guarantee that when a clone is requested, the received
+ pack is self contained and is connected.
+
If a helper advertises 'connect', Git will use it if possible and
fall back to another capability if the helper requests so when
connecting (see the 'connect' command under COMMANDS).
@@ -270,6 +274,9 @@ Optionally may output a 'lock <file>' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
suitably updated.
+
+If option 'check-connectivity' is requested, the helper must output
+'connectivity-ok' if the clone is self-contained and connected.
++
Supported if the helper has the "fetch" capability.
'push' +<src>:<dst>::
@@ -416,6 +423,9 @@ set by Git if the remote helper has the 'option' capability.
must not rely on this option being set before
connect request occurs.
+'option check-connectivity' \{'true'|'false'\}::
+ Request the helper to check connectivity of a clone.
+
SEE ALSO
--------
linkgit:git-remote[1]
View
52 glossary-content.txt
@@ -322,10 +322,54 @@ and a close parentheses `)`, and the remainder is the pattern to match
against the path.
+
The "magic signature" consists of an ASCII symbol that is not
-alphanumeric. Currently only the slash `/` is recognized as a
-"magic signature": it makes the pattern match from the root of
-the working tree, even when you are running the command from
-inside a subdirectory.
+alphanumeric.
++
+--
+top `/`;;
+ The magic word `top` (mnemonic: `/`) makes the pattern match
+ from the root of the working tree, even when you are running
+ the command from inside a subdirectory.
+
+literal;;
+ Wildcards in the pattern such as `*` or `?` are treated
+ as literal characters.
+
+icase;;
+ Case insensitive match.
+
+glob;;
+ Git treats the pattern as a shell glob suitable for
+ consumption by fnmatch(3) with the FNM_PATHNAME flag:
+ wildcards in the pattern will not match a / in the pathname.
+ For example, "Documentation/{asterisk}.html" matches
+ "Documentation/git.html" but not "Documentation/ppc/ppc.html"
+ or "tools/perf/Documentation/perf.html".
++
+Two consecutive asterisks ("`**`") in patterns matched against
+full pathname may have special meaning:
+
+ - A leading "`**`" followed by a slash means match in all
+ directories. For example, "`**/foo`" matches file or directory
+ "`foo`" anywhere, the same as pattern "`foo`". "**/foo/bar"
+ matches file or directory "`bar`" anywhere that is directly
+ under directory "`foo`".
+
+ - A trailing "/**" matches everything inside. For example,
+ "abc/**" matches all files inside directory "abc", relative
+ to the location of the `.gitignore` file, with infinite depth.
+
+ - A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, "`a/**/b`"
+ matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on.
+
+ - Other consecutive asterisks are considered invalid.
++
+Glob magic is incompatible with literal magic.
+--
++
+Currently only the slash `/` is recognized as the "magic signature",
+but it is envisioned that we will support more types of magic in later
+versions of Git.
+
A pathspec with only a colon means "there is no pathspec". This form
should not be combined with other pathspec.
View
16 line-range-format.txt
@@ -1,3 +1,5 @@
+<start> and <end> can take one of these forms:
+
- number
+
If <start> or <end> is a number, it specifies an
@@ -7,7 +9,10 @@ absolute line number (lines count from 1).
- /regex/
+
This form will use the first line matching the given
-POSIX regex. If <end> is a regex, it will search
+POSIX regex. If <start> is a regex, it will search from the end of
+the previous `-L` range, if any, otherwise from the start of file.
+If <start> is ``^/regex/'', it will search from the start of file.
+If <end> is a regex, it will search
starting at the line given by <start>.
+
@@ -15,11 +20,10 @@ starting at the line given by <start>.
+
This is only valid for <end> and will specify a number
of lines before or after the line given by <start>.
-+
-- :regex
+
-If the option's argument is of the form :regex, it denotes the range
+If ``:<regex>'' is given in place of <start> and <end>, it denotes the range
from the first funcname line that matches <regex>, up to the next
-funcname line.
-+
+funcname line. ``:<regex>'' searches from the end of the previous `-L` range,
+if any, otherwise from the start of file.
+``^:<regex>'' searches from the start of file.
View
46 technical/api-setup.html
@@ -763,20 +763,60 @@
setup_work_tree()
</p>
</li>
+</ul></div>
+<div class="paragraph"><p>(Dscho)</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_pathspec">Pathspec</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>See glossary-context.txt for the syntax of pathspec. In memory, a
+pathspec set is represented by "struct pathspec" and is prepared by
+parse_pathspec(). This function takes several arguments:</p></div>
+<div class="ulist"><ul>
<li>
<p>
-get_pathspec()
+magic_mask specifies what features that are NOT supported by the
+ following code. If a user attempts to use such a feature,
+ parse_pathspec() can reject it early.
+</p>
+</li>
+<li>
+<p>
+flags specifies other things that the caller wants parse_pathspec to
+ perform.
+</p>
+</li>
+<li>
+<p>
+prefix and args come from cmd_* functions
</p>
</li>
</ul></div>
-<div class="paragraph"><p>(Dscho)</p></div>
+<div class="paragraph"><p>get_pathspec() is obsolete and should never be used in new code.</p></div>
+<div class="paragraph"><p>parse_pathspec() helps catch unsupported features and reject them
+politely. At a lower level, different pathspec-related functions may
+not support the same set of features. Such pathspec-sensitive
+functions are guarded with GUARD_PATHSPEC(), which will die in an
+unfriendly way when an unsupported feature is requested.</p></div>
+<div class="paragraph"><p>The command designers are supposed to make sure that GUARD_PATHSPEC()
+never dies. They have to make sure all unsupported features are caught
+by parse_pathspec(), not by GUARD_PATHSPEC. grepping GUARD_PATHSPEC()
+should give the designers all pathspec-sensitive codepaths and what
+features they support.</p></div>
+<div class="paragraph"><p>A similar process is applied when a new pathspec magic is added. The
+designer lifts the GUARD_PATHSPEC restriction in the functions that
+support the new magic. At the same time (s)he has to make sure this
+new feature will be caught at parse_pathspec() in commands that cannot
+handle the new magic in some cases. grepping parse_pathspec() should
+help.</p></div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-09 15:34:20 PDT
</div>
</div>
</body>
View
38 technical/api-setup.txt
@@ -8,6 +8,42 @@ Talk about
* is_inside_git_dir()
* is_inside_work_tree()
* setup_work_tree()
-* get_pathspec()
(Dscho)
+
+Pathspec
+--------
+
+See glossary-context.txt for the syntax of pathspec. In memory, a
+pathspec set is represented by "struct pathspec" and is prepared by
+parse_pathspec(). This function takes several arguments:
+
+- magic_mask specifies what features that are NOT supported by the
+ following code. If a user attempts to use such a feature,
+ parse_pathspec() can reject it early.
+
+- flags specifies other things that the caller wants parse_pathspec to
+ perform.
+
+- prefix and args come from cmd_* functions
+
+get_pathspec() is obsolete and should never be used in new code.
+
+parse_pathspec() helps catch unsupported features and reject them
+politely. At a lower level, different pathspec-related functions may
+not support the same set of features. Such pathspec-sensitive
+functions are guarded with GUARD_PATHSPEC(), which will die in an
+unfriendly way when an unsupported feature is requested.
+
+The command designers are supposed to make sure that GUARD_PATHSPEC()
+never dies. They have to make sure all unsupported features are caught
+by parse_pathspec(), not by GUARD_PATHSPEC. grepping GUARD_PATHSPEC()
+should give the designers all pathspec-sensitive codepaths and what
+features they support.
+
+A similar process is applied when a new pathspec magic is added. The
+designer lifts the GUARD_PATHSPEC restriction in the functions that
+support the new magic. At the same time (s)he has to make sure this
+new feature will be caught at parse_pathspec() in commands that cannot
+handle the new magic in some cases. grepping parse_pathspec() should
+help.
View
48 user-manual.html
@@ -2291,10 +2291,50 @@
parenthesis <code class="literal">(</code>, a comma-separated list of zero or more "magic words",
and a close parentheses <code class="literal">)</code>, and the remainder is the pattern to match
against the path.</p><p class="simpara">The "magic signature" consists of an ASCII symbol that is not
-alphanumeric. Currently only the slash <code class="literal">/</code> is recognized as a
-"magic signature": it makes the pattern match from the root of
-the working tree, even when you are running the command from
-inside a subdirectory.</p><p class="simpara">A pathspec with only a colon means "there is no pathspec". This form
+alphanumeric.</p><div class="variablelist"><dl><dt><span class="term">
+top <code class="literal">/</code>
+</span></dt><dd>
+ The magic word <code class="literal">top</code> (mnemonic: <code class="literal">/</code>) makes the pattern match
+ from the root of the working tree, even when you are running
+ the command from inside a subdirectory.
+</dd><dt><span class="term">
+literal
+</span></dt><dd>
+ Wildcards in the pattern such as <code class="literal">*</code> or <code class="literal">?</code> are treated
+ as literal characters.
+</dd><dt><span class="term">
+icase
+</span></dt><dd>
+ Case insensitive match.
+</dd><dt><span class="term">
+glob
+</span></dt><dd><p class="simpara">
+ Git treats the pattern as a shell glob suitable for
+ consumption by fnmatch(3) with the FNM_PATHNAME flag:
+ wildcards in the pattern will not match a / in the pathname.
+ For example, "Documentation/*.html" matches
+ "Documentation/git.html" but not "Documentation/ppc/ppc.html"
+ or "tools/perf/Documentation/perf.html".
+</p><p class="simpara">Two consecutive asterisks ("<code class="literal">**</code>") in patterns matched against
+full pathname may have special meaning:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
+A leading "<code class="literal">**</code>" followed by a slash means match in all
+ directories. For example, "<code class="literal">**/foo</code>" matches file or directory
+ "<code class="literal">foo</code>" anywhere, the same as pattern "<code class="literal">foo</code>". "**/foo/bar"
+ matches file or directory "<code class="literal">bar</code>" anywhere that is directly
+ under directory "<code class="literal">foo</code>".
+</li><li class="listitem">
+A trailing "/<span class="strong"><strong>" matches everything inside. For example,
+ "abc/</strong></span>" matches all files inside directory "abc", relative
+ to the location of the <code class="literal">.gitignore</code> file, with infinite depth.
+</li><li class="listitem">
+A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, "<code class="literal">a/**/b</code>"
+ matches "<code class="literal">a/b</code>", "<code class="literal">a/x/b</code>", "<code class="literal">a/x/y/b</code>" and so on.
+</li><li class="listitem"><p class="simpara">
+Other consecutive asterisks are considered invalid.
+</p><p class="simpara">Glob magic is incompatible with literal magic.</p></li></ul></div></dd></dl></div><p class="simpara">Currently only the slash <code class="literal">/</code> is recognized as the "magic signature",
+but it is envisioned that we will support more types of magic in later
+versions of Git.</p><p class="simpara">A pathspec with only a colon means "there is no pathspec". This form
should not be combined with other pathspec.</p></dd><dt><span class="term">
<a name="def_parent"></a>parent
</span></dt><dd>
Please sign in to comment.
Something went wrong with that request. Please try again.