mirror of
https://github.com/git/git.git
synced 2024-05-29 14:26:11 +02:00
Merge branch 'ah/doc-updates'
Doc updates. * ah/doc-updates: doc: fix formatting in git-update-ref doc: fix indentation of listing blocks in gitweb.conf.txt doc: fix descripion for 'git tag --format' doc: fix inappropriate monospace formatting doc: fix ASCII art tab spacing doc: clarify boundaries of 'git worktree list --porcelain'
This commit is contained in:
Junio C Hamano
commit
90d228b0d7
|
|
@ -633,11 +633,11 @@ and so at step 3) we compute f(X).
|
|||
Let's take the following graph as an example:
|
||||
|
||||
-------------
|
||||
G-H-I-J
|
||||
/ \
|
||||
G-H-I-J
|
||||
/ \
|
||||
A-B-C-D-E-F O
|
||||
\ /
|
||||
K-L-M-N
|
||||
\ /
|
||||
K-L-M-N
|
||||
-------------
|
||||
|
||||
If we compute the following non optimal function on it:
|
||||
|
|
@ -649,25 +649,25 @@ g(X) = min(number_of_ancestors(X), number_of_descendants(X))
|
|||
we get:
|
||||
|
||||
-------------
|
||||
4 3 2 1
|
||||
G-H-I-J
|
||||
4 3 2 1
|
||||
G-H-I-J
|
||||
1 2 3 4 5 6/ \0
|
||||
A-B-C-D-E-F O
|
||||
\ /
|
||||
K-L-M-N
|
||||
4 3 2 1
|
||||
\ /
|
||||
K-L-M-N
|
||||
4 3 2 1
|
||||
-------------
|
||||
|
||||
but with the algorithm used by git bisect we get:
|
||||
|
||||
-------------
|
||||
7 7 6 5
|
||||
G-H-I-J
|
||||
7 7 6 5
|
||||
G-H-I-J
|
||||
1 2 3 4 5 6/ \0
|
||||
A-B-C-D-E-F O
|
||||
\ /
|
||||
K-L-M-N
|
||||
7 7 6 5
|
||||
\ /
|
||||
K-L-M-N
|
||||
7 7 6 5
|
||||
-------------
|
||||
|
||||
So we chose G, H, K or L as the best bisection point, which is better
|
||||
|
|
@ -773,7 +773,7 @@ forked of the main branch at a commit named "D" like this:
|
|||
-------------
|
||||
A-B-C-D-E-F-G <--main
|
||||
\
|
||||
H-I-J <--dev
|
||||
H-I-J <--dev
|
||||
-------------
|
||||
|
||||
The commit "D" is called a "merge base" for branch "main" and "dev"
|
||||
|
|
|
|||
|
|
@ -311,9 +311,9 @@ branch refers to a specific commit. Let's look at a repo with three
|
|||
commits, one of them tagged, and with branch 'master' checked out:
|
||||
|
||||
------------
|
||||
HEAD (refers to branch 'master')
|
||||
|
|
||||
v
|
||||
HEAD (refers to branch 'master')
|
||||
|
|
||||
v
|
||||
a---b---c branch 'master' (refers to commit 'c')
|
||||
^
|
||||
|
|
||||
|
|
@ -329,9 +329,9 @@ to commit 'd':
|
|||
------------
|
||||
$ edit; git add; git commit
|
||||
|
||||
HEAD (refers to branch 'master')
|
||||
|
|
||||
v
|
||||
HEAD (refers to branch 'master')
|
||||
|
|
||||
v
|
||||
a---b---c---d branch 'master' (refers to commit 'd')
|
||||
^
|
||||
|
|
||||
|
|
@ -398,7 +398,7 @@ at what happens when we then checkout master:
|
|||
------------
|
||||
$ git checkout master
|
||||
|
||||
HEAD (refers to branch 'master')
|
||||
HEAD (refers to branch 'master')
|
||||
e---f |
|
||||
/ v
|
||||
a---b---c---d branch 'master' (refers to commit 'd')
|
||||
|
|
|
|||
|
|
@ -154,13 +154,13 @@ topic origin/master`, the history of remote-tracking branch
|
|||
`origin/master` may have been rewound and rebuilt, leading to a
|
||||
history of this shape:
|
||||
|
||||
o---B2
|
||||
o---B2
|
||||
/
|
||||
---o---o---B1--o---o---o---B (origin/master)
|
||||
\
|
||||
B0
|
||||
B0
|
||||
\
|
||||
D0---D1---D (topic)
|
||||
D0---D1---D (topic)
|
||||
|
||||
where `origin/master` used to point at commits B0, B1, B2 and now it
|
||||
points at B, and your `topic` branch was started on top of it back
|
||||
|
|
|
|||
|
|
@ -187,6 +187,12 @@ This option is only applicable when listing tags without annotation lines.
|
|||
`--create-reflog`, but currently does not negate the setting of
|
||||
`core.logAllRefUpdates`.
|
||||
|
||||
--format=<format>::
|
||||
A string that interpolates `%(fieldname)` from a tag ref being shown
|
||||
and the object it points at. The format is the same as
|
||||
that of linkgit:git-for-each-ref[1]. When unspecified,
|
||||
defaults to `%(refname:strip=2)`.
|
||||
|
||||
<tagname>::
|
||||
The name of the tag to create, delete, or describe.
|
||||
The new tag name must pass all checks defined by
|
||||
|
|
@ -198,12 +204,6 @@ This option is only applicable when listing tags without annotation lines.
|
|||
The object that the new tag will refer to, usually a commit.
|
||||
Defaults to HEAD.
|
||||
|
||||
<format>::
|
||||
A string that interpolates `%(fieldname)` from a tag ref being shown
|
||||
and the object it points at. The format is the same as
|
||||
that of linkgit:git-for-each-ref[1]. When unspecified,
|
||||
defaults to `%(refname:strip=2)`.
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
By default, 'git tag' in sign-with-default mode (-s) will use your
|
||||
|
|
|
|||
|
|
@ -129,8 +129,8 @@ a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
|
|||
symbolic refs before creating the log name) describing the change
|
||||
in ref value. Log lines are formatted as:
|
||||
|
||||
. oldsha1 SP newsha1 SP committer LF
|
||||
+
|
||||
oldsha1 SP newsha1 SP committer LF
|
||||
|
||||
Where "oldsha1" is the 40 character hexadecimal value previously
|
||||
stored in <ref>, "newsha1" is the 40 character hexadecimal value of
|
||||
<newvalue> and "committer" is the committer's name, email address
|
||||
|
|
@ -138,8 +138,8 @@ and date in the standard Git committer ident format.
|
|||
|
||||
Optionally with -m:
|
||||
|
||||
. oldsha1 SP newsha1 SP committer TAB message LF
|
||||
+
|
||||
oldsha1 SP newsha1 SP committer TAB message LF
|
||||
|
||||
Where all fields are as described above and "message" is the
|
||||
value supplied to the -m option.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ SYNOPSIS
|
|||
[verse]
|
||||
'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
|
||||
[--advertise-refs] <directory>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Invoked by 'git fetch-pack', learns what
|
||||
|
|
|
|||
|
|
@ -270,8 +270,8 @@ Porcelain Format
|
|||
The porcelain format has a line per attribute. Attributes are listed with a
|
||||
label and value separated by a single space. Boolean attributes (like 'bare'
|
||||
and 'detached') are listed as a label only, and are only present if and only
|
||||
if the value is true. An empty line indicates the end of a worktree. For
|
||||
example:
|
||||
if the value is true. The first attribute of a worktree is always `worktree`,
|
||||
an empty line indicates the end of the record. For example:
|
||||
|
||||
------------
|
||||
$ git worktree list --porcelain
|
||||
|
|
|
|||
|
|
@ -402,11 +402,11 @@ Git so take care if using a foreign front-end.
|
|||
of Git object directories which can be used to search for Git
|
||||
objects. New objects will not be written to these directories.
|
||||
+
|
||||
Entries that begin with `"` (double-quote) will be interpreted
|
||||
as C-style quoted paths, removing leading and trailing
|
||||
double-quotes and respecting backslash escapes. E.g., the value
|
||||
`"path-with-\"-and-:-in-it":vanilla-path` has two paths:
|
||||
`path-with-"-and-:-in-it` and `vanilla-path`.
|
||||
Entries that begin with `"` (double-quote) will be interpreted
|
||||
as C-style quoted paths, removing leading and trailing
|
||||
double-quotes and respecting backslash escapes. E.g., the value
|
||||
`"path-with-\"-and-:-in-it":vanilla-path` has two paths:
|
||||
`path-with-"-and-:-in-it` and `vanilla-path`.
|
||||
|
||||
`GIT_DIR`::
|
||||
If the `GIT_DIR` environment variable is set then it
|
||||
|
|
|
|||
|
|
@ -303,21 +303,21 @@ number of pitfalls:
|
|||
attribute. If you decide to use the `working-tree-encoding` attribute
|
||||
in your repository, then it is strongly recommended to ensure that all
|
||||
clients working with the repository support it.
|
||||
|
||||
For example, Microsoft Visual Studio resources files (`*.rc`) or
|
||||
PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16.
|
||||
If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with
|
||||
a `working-tree-encoding` enabled Git client, then `foo.ps1` will be
|
||||
stored as UTF-8 internally. A client without `working-tree-encoding`
|
||||
support will checkout `foo.ps1` as UTF-8 encoded file. This will
|
||||
typically cause trouble for the users of this file.
|
||||
|
||||
If a Git client, that does not support the `working-tree-encoding`
|
||||
attribute, adds a new file `bar.ps1`, then `bar.ps1` will be
|
||||
stored "as-is" internally (in this example probably as UTF-16).
|
||||
A client with `working-tree-encoding` support will interpret the
|
||||
internal contents as UTF-8 and try to convert it to UTF-16 on checkout.
|
||||
That operation will fail and cause an error.
|
||||
+
|
||||
For example, Microsoft Visual Studio resources files (`*.rc`) or
|
||||
PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16.
|
||||
If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with
|
||||
a `working-tree-encoding` enabled Git client, then `foo.ps1` will be
|
||||
stored as UTF-8 internally. A client without `working-tree-encoding`
|
||||
support will checkout `foo.ps1` as UTF-8 encoded file. This will
|
||||
typically cause trouble for the users of this file.
|
||||
+
|
||||
If a Git client, that does not support the `working-tree-encoding`
|
||||
attribute, adds a new file `bar.ps1`, then `bar.ps1` will be
|
||||
stored "as-is" internally (in this example probably as UTF-16).
|
||||
A client with `working-tree-encoding` support will interpret the
|
||||
internal contents as UTF-8 and try to convert it to UTF-16 on checkout.
|
||||
That operation will fail and cause an error.
|
||||
|
||||
- Reencoding content to non-UTF encodings can cause errors as the
|
||||
conversion might not be UTF-8 round trip safe. If you suspect your
|
||||
|
|
|
|||
|
|
@ -67,7 +67,8 @@ submodule.<name>.fetchRecurseSubmodules::
|
|||
submodule.<name>.ignore::
|
||||
Defines under what circumstances "git status" and the diff family show
|
||||
a submodule as modified. The following values are supported:
|
||||
|
||||
+
|
||||
--
|
||||
all;; The submodule will never be considered modified (but will
|
||||
nonetheless show up in the output of status and commit when it has
|
||||
been staged).
|
||||
|
|
@ -84,12 +85,14 @@ submodule.<name>.ignore::
|
|||
differences, and modifications to tracked and untracked files are
|
||||
shown. This is the default option.
|
||||
|
||||
If this option is also present in the submodules entry in .git/config
|
||||
of the superproject, the setting there will override the one found in
|
||||
.gitmodules.
|
||||
Both settings can be overridden on the command line by using the
|
||||
"--ignore-submodule" option. The 'git submodule' commands are not
|
||||
affected by this setting.
|
||||
If this option is also present in the submodules entry in .git/config
|
||||
of the superproject, the setting there will override the one found in
|
||||
.gitmodules.
|
||||
|
||||
Both settings can be overridden on the command line by using the
|
||||
"--ignore-submodule" option. The 'git submodule' commands are not
|
||||
affected by this setting.
|
||||
--
|
||||
|
||||
submodule.<name>.shallow::
|
||||
When set to true, a clone of this submodule will be performed as a
|
||||
|
|
|
|||
|
|
@ -169,11 +169,15 @@ ACTIVE SUBMODULES
|
|||
|
||||
A submodule is considered active,
|
||||
|
||||
(a) if `submodule.<name>.active` is set to `true`
|
||||
or
|
||||
(b) if the submodule's path matches the pathspec in `submodule.active`
|
||||
or
|
||||
(c) if `submodule.<name>.url` is set.
|
||||
a. if `submodule.<name>.active` is set to `true`
|
||||
+
|
||||
or
|
||||
|
||||
b. if the submodule's path matches the pathspec in `submodule.active`
|
||||
+
|
||||
or
|
||||
|
||||
c. if `submodule.<name>.url` is set.
|
||||
|
||||
and these are evaluated in this order.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,10 +19,12 @@ end of a line is ignored. See *perlsyn*(1) for details.
|
|||
|
||||
An example:
|
||||
|
||||
# gitweb configuration file for http://git.example.org
|
||||
#
|
||||
our $projectroot = "/srv/git"; # FHS recommendation
|
||||
our $site_name = 'Example.org >> Repos';
|
||||
------------------------------------------------
|
||||
# gitweb configuration file for http://git.example.org
|
||||
#
|
||||
our $projectroot = "/srv/git"; # FHS recommendation
|
||||
our $site_name = 'Example.org >> Repos';
|
||||
------------------------------------------------
|
||||
|
||||
|
||||
The configuration file is used to override the default settings that
|
||||
|
|
@ -357,6 +359,7 @@ $home_link_str::
|
|||
+
|
||||
For example, the following setting produces a breadcrumb trail like
|
||||
"home / dev / projects / ..." where "projects" is the home link.
|
||||
+
|
||||
----------------------------------------------------------------------------
|
||||
our @extra_breadcrumbs = (
|
||||
[ 'home' => 'https://www.example.org/' ],
|
||||
|
|
@ -901,14 +904,16 @@ To enable blame, pickaxe search, and snapshot support (allowing "tar.gz" and
|
|||
"zip" snapshots), while allowing individual projects to turn them off, put
|
||||
the following in your GITWEB_CONFIG file:
|
||||
|
||||
$feature{'blame'}{'default'} = [1];
|
||||
$feature{'blame'}{'override'} = 1;
|
||||
--------------------------------------------------------------------------------
|
||||
$feature{'blame'}{'default'} = [1];
|
||||
$feature{'blame'}{'override'} = 1;
|
||||
|
||||
$feature{'pickaxe'}{'default'} = [1];
|
||||
$feature{'pickaxe'}{'override'} = 1;
|
||||
$feature{'pickaxe'}{'default'} = [1];
|
||||
$feature{'pickaxe'}{'override'} = 1;
|
||||
|
||||
$feature{'snapshot'}{'default'} = ['zip', 'tgz'];
|
||||
$feature{'snapshot'}{'override'} = 1;
|
||||
$feature{'snapshot'}{'default'} = ['zip', 'tgz'];
|
||||
$feature{'snapshot'}{'override'} = 1;
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
If you allow overriding for the snapshot feature, you can specify which
|
||||
snapshot formats are globally disabled. You can also add any command-line
|
||||
|
|
|
|||
Loading…
Reference in New Issue