diff --git a/MyFirstObjectWalk.html b/MyFirstObjectWalk.html index 68cf5595c..a9c7c2b37 100644 --- a/MyFirstObjectWalk.html +++ b/MyFirstObjectWalk.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/RelNotes/2.45.0.txt b/RelNotes/2.45.0.txt index 16a261315..b780bb89c 100644 --- a/RelNotes/2.45.0.txt +++ b/RelNotes/2.45.0.txt @@ -37,6 +37,14 @@ UI, Workflows & Features * Platform specific tweaks for OS/390 has been added to config.mak.uname. + * Users with safe.bareRepository=explicit can still work from within + $GIT_DIR of a seconary worktree (which resides at .git/worktrees/$name/) + of the primary worktree without explicitly specifying the $GIT_DIR + environment variable or the --git-dir= option. + + * The output format for dates "iso-strict" has been tweaked to show + a time in the Zulu timezone with "Z" suffix, instead of "+00:00". + Performance, Internal Implementation, Development Support etc. @@ -70,6 +78,21 @@ Performance, Internal Implementation, Development Support etc. * Some trace2 events that lacked def_param have learned to show it, enriching the output. + * The parse-options code that deals with abbreviated long option + names have been cleaned up. + + * The code in reftable backend that creates new table files works + better with the tempfile framework to avoid leaving cruft after a + failure. + + * The reftable code has its own custom binary search function whose + comparison callback has an unusual interface, which caused the + binary search to degenerate into a linear search, which has been + corrected. + + * The code to iterate over reflogs in the reftable has been optimized + to reduce memory allocation and deallocation. + Fixes since v2.44 ----------------- @@ -180,6 +203,17 @@ Fixes since v2.44 variable that is no longer used. (merge 72a8d3f027 pw/rebase-i-ignore-cherry-pick-help-environment later to maint). + * The code to find the effective end of log message can fall into an + endless loop, which has been corrected. + (merge 2541cba2d6 fs/find-end-of-log-message-fix later to maint). + + * Mark-ups used in the documentation has been improved for + consistency. + (merge 45d5ed3e50 ja/doc-markup-fixes later to maint). + + * The status.showUntrackedFiles configuration variable was + incorrectly documented to accept "false", which has been corrected. + * Other code cleanup, docfix, build fix, etc. (merge f0e578c69c rs/use-xstrncmpz later to maint). (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint). @@ -198,3 +232,4 @@ Fixes since v2.44 (merge 5f78d52dce es/config-doc-sort-sections later to maint). (merge 781fb7b4c2 as/option-names-in-messages later to maint). (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to maint). + (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint). diff --git a/ReviewingGuidelines.html b/ReviewingGuidelines.html index 13ad3a228..80828f7cf 100644 --- a/ReviewingGuidelines.html +++ b/ReviewingGuidelines.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/SubmittingPatches.html b/SubmittingPatches.html index b0f3470d1..79b94d578 100644 --- a/SubmittingPatches.html +++ b/SubmittingPatches.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/ToolsForGit.html b/ToolsForGit.html index 67efbb66a..9b4baa934 100644 --- a/ToolsForGit.html +++ b/ToolsForGit.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/everyday.html b/everyday.html index aaba14c44..45f4e4139 100644 --- a/everyday.html +++ b/everyday.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/git-clone.html b/git-clone.html index 6e42518f8..8195bf02c 100644 --- a/git-clone.html +++ b/git-clone.html @@ -862,9 +862,9 @@ objects from the source repository into a pack in the cloned repository.

- If the reference repository is on the local machine, + If the reference <repository> is on the local machine, automatically setup .git/objects/info/alternates to - obtain objects from the reference repository. Using + obtain objects from the reference <repository>. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. @@ -956,7 +956,7 @@ objects from the source repository into a pack in the cloned repository.

Fail if the source repository is a shallow repository. - The clone.rejectShallow configuration variable can be used to + The clone.rejectShallow configuration variable can be used to specify the default.

@@ -966,8 +966,8 @@ objects from the source repository into a pack in the cloned repository.

Make a bare Git repository. That is, instead of - creating <directory> and placing the administrative - files in <directory>/.git, make the <directory> + creating <directory> and placing the administrative + files in <directory>/.git, make the <directory> itself the $GIT_DIR. This obviously implies the --no-checkout because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly @@ -995,11 +995,11 @@ objects from the source repository into a pack in the cloned repository.

Use the partial clone feature and request that the server sends a subset of reachable objects according to a given object filter. - When using --filter, the supplied <filter-spec> is used for + When using --filter, the supplied <filter-spec> is used for the partial clone filter. For example, --filter=blob:none will filter out all blobs (file contents) until needed by Git. Also, --filter=blob:limit=<size> will filter out all blobs of size - at least <size>. For more details on filter specifications, see + at least <size>. For more details on filter specifications, see the --filter option in git-rev-list(1).

@@ -1035,7 +1035,7 @@ objects from the source repository into a pack in the cloned repository.

Instead of using the remote name origin to keep track of the upstream - repository, use <name>. Overrides clone.defaultRemoteName from the + repository, use <name>. Overrides clone.defaultRemoteName from the config.

@@ -1048,7 +1048,7 @@ objects from the source repository into a pack in the cloned repository.

Instead of pointing the newly created HEAD to the branch pointed - to by the cloned repository’s HEAD, point to <name> branch + to by the cloned repository’s HEAD, point to <name> branch instead. In a non-bare repository, this is the branch that will be checked out. --branch can also take tags and detaches the HEAD at that commit @@ -1088,7 +1088,7 @@ objects from the source repository into a pack in the cloned repository.

<key> is in the same format as expected by git-config(1) (e.g., core.eol=true). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add @@ -1140,7 +1140,7 @@ corresponding --mirror and --no-tags options instead.< branch remote’s HEAD points at. Further fetches into the resulting repository will only update the remote-tracking branch for the branch this option was used for the - initial cloning. If the HEAD at the remote did not point at any + initial cloning. If the HEAD at the remote did not point at any branch when --single-branch clone was made, no remote-tracking branch is created.

@@ -1167,7 +1167,7 @@ branch of some repository for search indexing.

After the clone is created, initialize and clone submodules - within based on the provided pathspec. If no pathspec is + within based on the provided <pathspec>. If no =<pathspec> is provided, all submodules are initialized and cloned. This option can be given multiple times for pathspecs consisting of multiple entries. The resulting clone has submodule.active set to @@ -1250,7 +1250,7 @@ Specify the given ref storage format for the repository. The valid values are:

- The (possibly remote) repository to clone from. See the + The (possibly remote) <repository> to clone from. See the GIT URLS section below for more information on specifying repositories.

@@ -1261,7 +1261,7 @@ Specify the given ref storage format for the repository. The valid values are:

The name of a new directory to clone into. The "humanish" - part of the source repository is used if no directory is + part of the source repository is used if no <directory> is explicitly given (repo for /path/to/repo.git and foo for host.xz:foo/.git). Cloning into an existing directory is only allowed if the directory is empty. @@ -1273,7 +1273,7 @@ Specify the given ref storage format for the repository. The valid values are:

Before fetching from the remote, fetch a bundle from the given - <uri> and unbundle the data into the local repository. The refs + <uri> and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden refs/bundle/* namespace. This option is incompatible with --depth, --shallow-since, and --shallow-exclude. @@ -1363,21 +1363,21 @@ file:///path/to/repo.git/

These two syntaxes are mostly equivalent, except the former implies ---local option.

git clone, git fetch and git pull, but not git push, will also +--local option.

git clone, git fetch and git pull, but not git push, will also accept a suitable bundle file. See git-bundle(1).

When Git doesn’t know how to handle a certain transport protocol, it -attempts to use the remote-<transport> remote helper, if one +attempts to use the remote-<transport> remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used:

-<transport>::<address> +<transport>::_<address>_

where <address> may be a path, a server and path, or an arbitrary +

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See gitremote-helpers(7) for details.

If there are a large number of similarly-named remote repositories and @@ -1478,8 +1478,7 @@ init.templateDir

- Specify the directory from which templates will be copied. - (See the "TEMPLATE DIRECTORY" section of git-init(1).) + Specify the directory from which templates will be copied. (See the "TEMPLATE DIRECTORY" section of git-init(1).)

@@ -1534,7 +1533,7 @@ clone.filterSubmodules diff --git a/git-clone.txt b/git-clone.txt index 0c07720c6..f90977a85 100644 --- a/git-clone.txt +++ b/git-clone.txt @@ -102,9 +102,9 @@ its source repository, you can simply run `git repack -a` to copy all objects from the source repository into a pack in the cloned repository. --reference[-if-able] :: - If the reference repository is on the local machine, + If the reference __ is on the local machine, automatically setup `.git/objects/info/alternates` to - obtain objects from the reference repository. Using + obtain objects from the reference __. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. @@ -156,13 +156,13 @@ objects from the source repository into a pack in the cloned repository. --[no-]reject-shallow:: Fail if the source repository is a shallow repository. - The 'clone.rejectShallow' configuration variable can be used to + The `clone.rejectShallow` configuration variable can be used to specify the default. --bare:: Make a 'bare' Git repository. That is, instead of - creating `` and placing the administrative - files in `/.git`, make the `` + creating __ and placing the administrative + files in `/.git`, make the __ itself the `$GIT_DIR`. This obviously implies the `--no-checkout` because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly @@ -180,11 +180,11 @@ objects from the source repository into a pack in the cloned repository. --filter=:: Use the partial clone feature and request that the server sends a subset of reachable objects according to a given object filter. - When using `--filter`, the supplied `` is used for + When using `--filter`, the supplied __ is used for the partial clone filter. For example, `--filter=blob:none` will filter out all blobs (file contents) until needed by Git. Also, `--filter=blob:limit=` will filter out all blobs of size - at least ``. For more details on filter specifications, see + at least __. For more details on filter specifications, see the `--filter` option in linkgit:git-rev-list[1]. --also-filter-submodules:: @@ -203,13 +203,13 @@ objects from the source repository into a pack in the cloned repository. -o :: --origin :: Instead of using the remote name `origin` to keep track of the upstream - repository, use ``. Overrides `clone.defaultRemoteName` from the + repository, use __. Overrides `clone.defaultRemoteName` from the config. -b :: --branch :: Instead of pointing the newly created HEAD to the branch pointed - to by the cloned repository's HEAD, point to `` branch + to by the cloned repository's HEAD, point to __ branch instead. In a non-bare repository, this is the branch that will be checked out. `--branch` can also take tags and detaches the HEAD at that commit @@ -230,7 +230,7 @@ objects from the source repository into a pack in the cloned repository. Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any - files checked out. The key is in the same format as expected by + files checked out. The __ is in the same format as expected by linkgit:git-config[1] (e.g., `core.eol=true`). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add @@ -263,7 +263,7 @@ corresponding `--mirror` and `--no-tags` options instead. branch remote's `HEAD` points at. Further fetches into the resulting repository will only update the remote-tracking branch for the branch this option was used for the - initial cloning. If the HEAD at the remote did not point at any + initial cloning. If the `HEAD` at the remote did not point at any branch when `--single-branch` clone was made, no remote-tracking branch is created. @@ -281,7 +281,7 @@ branch of some repository for search indexing. --recurse-submodules[=]:: After the clone is created, initialize and clone submodules - within based on the provided pathspec. If no pathspec is + within based on the provided __. If no _=_ is provided, all submodules are initialized and cloned. This option can be given multiple times for pathspecs consisting of multiple entries. The resulting clone has `submodule.active` set to @@ -323,20 +323,20 @@ include::ref-storage-format.txt[] Defaults to the `submodule.fetchJobs` option. :: - The (possibly remote) repository to clone from. See the + The (possibly remote) __ to clone from. See the <> section below for more information on specifying repositories. :: The name of a new directory to clone into. The "humanish" - part of the source repository is used if no directory is + part of the source repository is used if no __ is explicitly given (`repo` for `/path/to/repo.git` and `foo` for `host.xz:foo/.git`). Cloning into an existing directory is only allowed if the directory is empty. --bundle-uri=:: Before fetching from the remote, fetch a bundle from the given - `` and unbundle the data into the local repository. The refs + __ and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden `refs/bundle/*` namespace. This option is incompatible with `--depth`, `--shallow-since`, and `--shallow-exclude`. diff --git a/git-config.html b/git-config.html index a8c37bda9..101cfd1d6 100644 --- a/git-config.html +++ b/git-config.html @@ -7865,13 +7865,14 @@ index.skipHash refuse to parse the index and Git clients older than 2.40.0 will report an error during git fsck.

init.templateDir: - Specify the directory from which templates will be copied. - (See the "TEMPLATE DIRECTORY" section of git-init(1).) + Specify the directory from which templates will be copied. (See the "TEMPLATE DIRECTORY" section of git-init(1).)
diff --git a/git-fetch.html b/git-fetch.html index c026f417a..911f2cf73 100644 --- a/git-fetch.html +++ b/git-fetch.html @@ -1511,22 +1511,22 @@ file:///path/to/repo.git/

These two syntaxes are mostly equivalent, except when cloning, when -the former implies --local option. See git-clone(1) for +the former implies --local option. See git-clone(1) for details.

git clone, git fetch and git pull, but not git push, will also +

git clone, git fetch and git pull, but not git push, will also accept a suitable bundle file. See git-bundle(1).

-<transport>::<address> +<transport>::_<address>_

where <address> may be a path, a server and path, or an arbitrary +

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See gitremote-helpers(7) for details.

If there are a large number of similarly-named remote repositories and diff --git a/git-init.html b/git-init.html index d289f2584..51c139e95 100644 --- a/git-init.html +++ b/git-init.html @@ -772,10 +772,10 @@ to use instead of ./.git for the base of the repository.

$GIT_OBJECT_DIRECTORY environment variable then the sha1 directories are created underneath; otherwise, the default $GIT_DIR/objects directory is used.

Running git init in an existing repository is safe. It will not +

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

+rerunning git init is to pick up newly added templates (or to move +the repository to another place if --separate-git-dir is given).

@@ -807,8 +807,8 @@ current working directory.

-Specify the given object format (hash algorithm) for the repository. The valid -values are sha1 and (if enabled) sha256. sha1 is the default. +Specify the given object <format> (hash algorithm) for the repository. The valid +values are sha1 and (if enabled) sha256. sha1 is the default.

Note: At present, there is no interoperability between SHA-256 repositories and SHA-1 repositories.

@@ -826,7 +826,7 @@ without data loss.

-Specify the given ref storage format for the repository. The valid values are: +Specify the given ref storage <format> for the repository. The valid values are:

@@ -871,7 +871,7 @@ repository.
-Use the specified name for the initial branch in the newly created +Use <branch-name> for the initial branch in the newly created repository. If not specified, fall back to the default name (currently master, but this is subject to change in the future; the name can be customized via the init.defaultBranch configuration variable). @@ -884,18 +884,21 @@ customized via the init.defaultBranch configuration variable).
Specify that the Git repository is to be shared amongst several users. This allows users belonging to the same group to push into that -repository. When specified, the config variable "core.sharedRepository" is +repository. When specified, the config variable core.sharedRepository is set so that files and directories under $GIT_DIR are created with the requested permissions. When not specified, Git will use permissions reported -by umask(2). +by umask(2).
-
The option can have the following values, defaulting to group if no value +
The option can have the following values, defaulting to group if no value is given:
-umask (or false) +umask +
+
+false

@@ -904,36 +907,45 @@ specified.

-group (or true) +group +
+
+true

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

-all (or world or everybody) +all +
+
+world +
+
+everybody

-Same as group, but make the repository readable by all users. +Same as group, but make the repository readable by all users.

-<perm> +<perm>

<perm> is a 3-digit octal number prefixed with ‘0` and each file -will have mode <perm>. <perm> will override users’ umask(2) -value (and not only loosen permissions as group and all -do). 0640 will create a repository which is group-readable, but -not group-writable or accessible to others. 0660 will create a repo +will have mode <perm>. <perm> will override users’umask(2) +value (and not only loosen permissions as group and all +do). 0640 will create a repository which is group-readable, but +not group-writable or accessible to others. 0660 will create a repo that is readable and writable to the current user and group, but inaccessible to others (directories and executable files get their x bit from the r bit for corresponding classes of users). @@ -946,7 +958,7 @@ inaccessible to others (directories and executable files get their
By default, the configuration flag receive.denyNonFastForwards is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it.
-
If you provide a directory, the command is run inside it. If this directory +
If you provide a <directory>, the command is run inside it. If this directory does not exist, it will be created.

@@ -1003,7 +1015,7 @@ $ git commit <3>

-Create a /path/to/my/codebase/.git directory. +Create a /path/to/my/codebase/.git directory.

@@ -1033,8 +1045,7 @@ init.templateDir

- Specify the directory from which templates will be copied. - (See the "TEMPLATE DIRECTORY" section of git-init(1).) + Specify the directory from which templates will be copied.

@@ -1060,7 +1071,7 @@ init.defaultBranch

Last updated - 2024-01-16 12:41:37 PST + 2024-03-21 16:28:38 PDT

diff --git a/git-init.txt b/git-init.txt index e8dc645bb..2f864e11e 100644 --- a/git-init.txt +++ b/git-init.txt @@ -33,10 +33,10 @@ If the object storage directory is specified via the are created underneath; otherwise, the default `$GIT_DIR/objects` directory is used. -Running 'git init' in an existing repository is safe. It will not +Running `git init` in an existing repository is safe. It will not overwrite things that are already there. The primary reason for -rerunning 'git init' is to pick up newly added templates (or to move -the repository to another place if --separate-git-dir is given). +rerunning `git init` is to pick up newly added templates (or to move +the repository to another place if `--separate-git-dir` is given). OPTIONS ------- @@ -53,14 +53,14 @@ current working directory. --object-format=:: -Specify the given object format (hash algorithm) for the repository. The valid -values are 'sha1' and (if enabled) 'sha256'. 'sha1' is the default. +Specify the given object __ (hash algorithm) for the repository. The valid +values are `sha1` and (if enabled) `sha256`. `sha1` is the default. + include::object-format-disclaimer.txt[] --ref-format=:: -Specify the given ref storage format for the repository. The valid values are: +Specify the given ref storage __ for the repository. The valid values are: + include::ref-storage-format.txt[] @@ -81,7 +81,7 @@ If this is a reinitialization, the repository will be moved to the specified pat -b :: --initial-branch=:: -Use the specified name for the initial branch in the newly created +Use __ for the initial branch in the newly created repository. If not specified, fall back to the default name (currently `master`, but this is subject to change in the future; the name can be customized via the `init.defaultBranch` configuration variable). @@ -90,40 +90,44 @@ customized via the `init.defaultBranch` configuration variable). Specify that the Git repository is to be shared amongst several users. This allows users belonging to the same group to push into that -repository. When specified, the config variable "core.sharedRepository" is +repository. When specified, the config variable `core.sharedRepository` is set so that files and directories under `$GIT_DIR` are created with the requested permissions. When not specified, Git will use permissions reported -by umask(2). +by `umask(2)`. + -The option can have the following values, defaulting to 'group' if no value +The option can have the following values, defaulting to `group` if no value is given: + -- -'umask' (or 'false'):: +umask:: +false:: Use permissions reported by umask(2). The default, when `--shared` is not specified. -'group' (or 'true'):: +group:: +true:: Make the repository group-writable, (and g+sx, since the git group may not be the primary group of all users). This is used to loosen the permissions of an otherwise safe umask(2) value. Note that the umask still applies to the other -permission bits (e.g. if umask is '0022', using 'group' will not remove read -privileges from other (non-group) users). See '0xxx' for how to exactly specify +permission bits (e.g. if umask is `0022`, using `group` will not remove read +privileges from other (non-group) users). See `0xxx` for how to exactly specify the repository permissions. -'all' (or 'world' or 'everybody'):: +all:: +world:: +everybody:: -Same as 'group', but make the repository readable by all users. +Same as `group`, but make the repository readable by all users. -'':: +:: -'' is a 3-digit octal number prefixed with `0` and each file -will have mode ''. '' will override users' umask(2) -value (and not only loosen permissions as 'group' and 'all' -do). '0640' will create a repository which is group-readable, but -not group-writable or accessible to others. '0660' will create a repo +__ is a 3-digit octal number prefixed with `0` and each file +will have mode __. __ will override users'`umask(2)` +value (and not only loosen permissions as `group` and `all` +do). `0640` will create a repository which is group-readable, but +not group-writable or accessible to others. `0660` will create a repo that is readable and writable to the current user and group, but inaccessible to others (directories and executable files get their `x` bit from the `r` bit for corresponding classes of users). @@ -133,7 +137,7 @@ By default, the configuration flag `receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you provide a 'directory', the command is run inside it. If this directory +If you provide a __, the command is run inside it. If this directory does not exist, it will be created. TEMPLATE DIRECTORY @@ -172,7 +176,7 @@ $ git add . <2> $ git commit <3> ---------------- + -<1> Create a /path/to/my/codebase/.git directory. +<1> Create a `/path/to/my/codebase/.git` directory. <2> Add all existing files to the index. <3> Record the pristine state as the first commit in the history. @@ -181,6 +185,8 @@ CONFIGURATION include::includes/cmd-config-section-all.txt[] +:git-init: + include::config/init.txt[] GIT diff --git a/git-pull.html b/git-pull.html index a3cf05308..60b3080b6 100644 --- a/git-pull.html +++ b/git-pull.html @@ -1739,22 +1739,22 @@ file:///path/to/repo.git/

These two syntaxes are mostly equivalent, except when cloning, when -the former implies --local option. See git-clone(1) for +the former implies --local option. See git-clone(1) for details.

git clone, git fetch and git pull, but not git push, will also +

git clone, git fetch and git pull, but not git push, will also accept a suitable bundle file. See git-bundle(1).

-<transport>::<address> +<transport>::_<address>_

where <address> may be a path, a server and path, or an arbitrary +

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See gitremote-helpers(7) for details.

If there are a large number of similarly-named remote repositories and diff --git a/git-push.html b/git-push.html index 6cd8c752f..fef78f778 100644 --- a/git-push.html +++ b/git-push.html @@ -1405,22 +1405,22 @@ file:///path/to/repo.git/

These two syntaxes are mostly equivalent, except when cloning, when -the former implies --local option. See git-clone(1) for +the former implies --local option. See git-clone(1) for details.

git clone, git fetch and git pull, but not git push, will also +

git clone, git fetch and git pull, but not git push, will also accept a suitable bundle file. See git-bundle(1).

-<transport>::<address> +<transport>::_<address>_

where <address> may be a path, a server and path, or an arbitrary +

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See gitremote-helpers(7) for details.

If there are a large number of similarly-named remote repositories and diff --git a/git-remote-helpers.html b/git-remote-helpers.html index d06a57157..496a3d2d4 100644 --- a/git-remote-helpers.html +++ b/git-remote-helpers.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/git-status.html b/git-status.html index 92fb4888b..f8cd29158 100644 --- a/git-status.html +++ b/git-status.html @@ -1389,7 +1389,7 @@ results, so it could be faster on subsequent runs.

The --untracked-files=no flag or the - status.showUntrackedfiles=false config (see above for both): + status.showUntrackedFiles=no config (see above for both): indicate that git status should not report untracked files. This is the fastest option. git status will not list the untracked files, so you need to be careful to remember if @@ -1464,7 +1464,7 @@ normal.

diff --git a/git-status.txt b/git-status.txt index 4dbb88373..b0f36fabf 100644 --- a/git-status.txt +++ b/git-status.txt @@ -472,7 +472,7 @@ again, because your configuration may already be caching `git status` results, so it could be faster on subsequent runs. * The `--untracked-files=no` flag or the - `status.showUntrackedfiles=false` config (see above for both): + `status.showUntrackedFiles=no` config (see above for both): indicate that `git status` should not report untracked files. This is the fastest option. `git status` will not list the untracked files, so you need to be careful to remember if diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html index 3276b1e55..4b531602c 100644 --- a/howto/coordinate-embargoed-releases.html +++ b/howto/coordinate-embargoed-releases.html @@ -1038,7 +1038,7 @@ Thanks, diff --git a/howto/keep-canonical-history-correct.html b/howto/keep-canonical-history-correct.html index cfe0c1295..4c7cc9df4 100644 --- a/howto/keep-canonical-history-correct.html +++ b/howto/keep-canonical-history-correct.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -939,7 +939,7 @@ tip of your master again and redo the two merges:

diff --git a/howto/maintain-git.html b/howto/maintain-git.html index 871a6d2e5..7a2b64361 100644 --- a/howto/maintain-git.html +++ b/howto/maintain-git.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1479,7 +1479,7 @@ $ git update-ref -d $mf/ai/topic diff --git a/howto/new-command.html b/howto/new-command.html index 1790f37c9..5bcebaa71 100644 --- a/howto/new-command.html +++ b/howto/new-command.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -864,7 +864,7 @@ letter [PATCH 0/n]. diff --git a/howto/rebase-from-internal-branch.html b/howto/rebase-from-internal-branch.html index d38ad6658..b5d3f5bb7 100644 --- a/howto/rebase-from-internal-branch.html +++ b/howto/rebase-from-internal-branch.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -896,7 +896,7 @@ the #1' commit.

diff --git a/howto/rebuild-from-update-hook.html b/howto/rebuild-from-update-hook.html index 73ba7e8bb..70c69994a 100644 --- a/howto/rebuild-from-update-hook.html +++ b/howto/rebuild-from-update-hook.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -848,7 +848,7 @@ This is still crude and does not protect against simultaneous diff --git a/howto/recover-corrupted-blob-object.html b/howto/recover-corrupted-blob-object.html index 5a06bb776..e20af0454 100644 --- a/howto/recover-corrupted-blob-object.html +++ b/howto/recover-corrupted-blob-object.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -881,7 +881,7 @@ thing.

diff --git a/howto/recover-corrupted-object-harder.html b/howto/recover-corrupted-object-harder.html index b0e295a81..100b2308c 100644 --- a/howto/recover-corrupted-object-harder.html +++ b/howto/recover-corrupted-object-harder.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1190,7 +1190,7 @@ int main(int argc, char **argv) diff --git a/howto/revert-a-faulty-merge.html b/howto/revert-a-faulty-merge.html index 60f850f24..d01b50de3 100644 --- a/howto/revert-a-faulty-merge.html +++ b/howto/revert-a-faulty-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1026,7 +1026,7 @@ P---o---o---M---x---x---W---x---M2 diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index b05e65db0..031214dbd 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -908,7 +908,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f diff --git a/howto/separating-topic-branches.html b/howto/separating-topic-branches.html index 910f5e717..65935fa04 100644 --- a/howto/separating-topic-branches.html +++ b/howto/separating-topic-branches.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -842,7 +842,7 @@ o---o"master" diff --git a/howto/setup-git-server-over-http.html b/howto/setup-git-server-over-http.html index 62634c0e5..7742060d9 100644 --- a/howto/setup-git-server-over-http.html +++ b/howto/setup-git-server-over-http.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1072,7 +1072,7 @@ help diagnosing the problem, but removes security checks.

diff --git a/howto/update-hook-example.html b/howto/update-hook-example.html index c6da93fc6..5f1216d37 100644 --- a/howto/update-hook-example.html +++ b/howto/update-hook-example.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -931,7 +931,7 @@ that JC can make non-fast-forward pushes on it.

diff --git a/howto/use-git-daemon.html b/howto/use-git-daemon.html index 88ca012d7..3d79ffdbe 100644 --- a/howto/use-git-daemon.html +++ b/howto/use-git-daemon.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -792,7 +792,7 @@ a good practice to put the paths after a "--" separator.

diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index 6ee70d534..68c22f258 100644 --- a/howto/using-merge-subtree.html +++ b/howto/using-merge-subtree.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -849,7 +849,7 @@ Please note that if the other project merges from you, then it will diff --git a/howto/using-signed-tag-in-pull-request.html b/howto/using-signed-tag-in-pull-request.html index 3402f5397..aae722138 100644 --- a/howto/using-signed-tag-in-pull-request.html +++ b/howto/using-signed-tag-in-pull-request.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -953,7 +953,7 @@ as part of the merge commit.

diff --git a/technical/api-error-handling.html b/technical/api-error-handling.html index 57227a0d0..8a70666ae 100644 --- a/technical/api-error-handling.html +++ b/technical/api-error-handling.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-index.html b/technical/api-index.html index ca28ada14..895ecd1e3 100644 --- a/technical/api-index.html +++ b/technical/api-index.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-merge.html b/technical/api-merge.html index 2ae12b8aa..b130786ea 100644 --- a/technical/api-merge.html +++ b/technical/api-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-parse-options.html b/technical/api-parse-options.html index eaffd28b0..d013b78d0 100644 --- a/technical/api-parse-options.html +++ b/technical/api-parse-options.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-simple-ipc.html b/technical/api-simple-ipc.html index 50f7f1c01..6f086e8f6 100644 --- a/technical/api-simple-ipc.html +++ b/technical/api-simple-ipc.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-trace2.html b/technical/api-trace2.html index ef6b2b4b3..e2a86b8da 100644 --- a/technical/api-trace2.html +++ b/technical/api-trace2.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/bitmap-format.html b/technical/bitmap-format.html index d779ffc75..3a1b9a011 100644 --- a/technical/bitmap-format.html +++ b/technical/bitmap-format.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/bundle-uri.html b/technical/bundle-uri.html index c5f53fc9f..bc3746d72 100644 --- a/technical/bundle-uri.html +++ b/technical/bundle-uri.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/hash-function-transition.html b/technical/hash-function-transition.html index 4b8f8f139..037d72daa 100644 --- a/technical/hash-function-transition.html +++ b/technical/hash-function-transition.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/long-running-process-protocol.html b/technical/long-running-process-protocol.html index 5a0b2b74f..4731b15b4 100644 --- a/technical/long-running-process-protocol.html +++ b/technical/long-running-process-protocol.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/multi-pack-index.html b/technical/multi-pack-index.html index a5efcc624..e1905dfe4 100644 --- a/technical/multi-pack-index.html +++ b/technical/multi-pack-index.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/pack-heuristics.html b/technical/pack-heuristics.html index ea7b1cb07..b1f208edf 100644 --- a/technical/pack-heuristics.html +++ b/technical/pack-heuristics.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/parallel-checkout.html b/technical/parallel-checkout.html index 622c2e176..fba36deb1 100644 --- a/technical/parallel-checkout.html +++ b/technical/parallel-checkout.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/partial-clone.html b/technical/partial-clone.html index ff21d4d4c..7ff67a695 100644 --- a/technical/partial-clone.html +++ b/technical/partial-clone.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/racy-git.html b/technical/racy-git.html index 14dd0b352..9dda9a30b 100644 --- a/technical/racy-git.html +++ b/technical/racy-git.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/scalar.html b/technical/scalar.html index 74dfd2d41..04da07916 100644 --- a/technical/scalar.html +++ b/technical/scalar.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/send-pack-pipeline.html b/technical/send-pack-pipeline.html index 96a36ffca..9c696379b 100644 --- a/technical/send-pack-pipeline.html +++ b/technical/send-pack-pipeline.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/shallow.html b/technical/shallow.html index 44699a40f..43b5ae91d 100644 --- a/technical/shallow.html +++ b/technical/shallow.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/trivial-merge.html b/technical/trivial-merge.html index 1b9f713df..35a9afe78 100644 --- a/technical/trivial-merge.html +++ b/technical/trivial-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/unit-tests.html b/technical/unit-tests.html index 18efe9ba1..0f98a782a 100644 --- a/technical/unit-tests.html +++ b/technical/unit-tests.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/urls.txt b/urls.txt index ce671f812..0b9e0c430 100644 --- a/urls.txt +++ b/urls.txt @@ -44,26 +44,26 @@ syntaxes may be used: ifndef::git-clone[] These two syntaxes are mostly equivalent, except when cloning, when -the former implies --local option. See linkgit:git-clone[1] for +the former implies `--local` option. See linkgit:git-clone[1] for details. endif::git-clone[] ifdef::git-clone[] These two syntaxes are mostly equivalent, except the former implies ---local option. +`--local` option. endif::git-clone[] -'git clone', 'git fetch' and 'git pull', but not 'git push', will also +`git clone`, `git fetch` and `git pull`, but not `git push`, will also accept a suitable bundle file. See linkgit:git-bundle[1]. When Git doesn't know how to handle a certain transport protocol, it -attempts to use the 'remote-' remote helper, if one +attempts to use the `remote-` remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used: -- ::

+- __::_

_ -where

may be a path, a server and path, or an arbitrary +where _

_ may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See linkgit:gitremote-helpers[7] for details. diff --git a/user-manual.html b/user-manual.html index a3188631b..556a64719 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1,5 +1,5 @@ -Git User Manual

Git User Manual

Revision History
	2024-03-18

Table of Contents

Introduction

1. Repositories and Branches

How to get a Git repository

How to check out a different version of a project

Understanding History: Commits

Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?

Manipulating branches

Examining an old version without creating a new branch

Examining branches from a remote repository

Naming branches, tags, and other references

Updating a repository with git fetch

Fetching branches from other repositories

2. Exploring Git history

How to use bisect to find a regression

Naming commits

Creating tags

Browsing revisions

Generating diffs

Viewing old file versions

Examples

Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content

3. Developing with Git

Telling Git your name

Creating a new repository

How to make a commit

Creating good commit messages

Ignoring files

How to merge

Resolving a merge

Getting conflict-resolution help during a merge

Undoing a merge

Fast-forward merges

Fixing mistakes

Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress

Ensuring good performance

Ensuring reliability

Checking the repository for corruption
Recovering lost changes

4. Sharing development with others

Getting updates with git pull

Submitting patches to a project

Importing patches to a project

Public Git repositories

Setting up a public repository
Exporting a Git repository via the Git protocol
Exporting a git repository via HTTP
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository

How to get a Git repository with minimal history

Examples

Maintaining topic branches for a Linux subsystem maintainer

5. Rewriting history and maintaining patch series

Creating the perfect patch series
Keeping a patch series up to date using git rebase
Rewriting a single commit
Reordering or selecting from a patch series
Using interactive rebases
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history

6. Advanced branch management

Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote-tracking branches

7. Git concepts

The Object Database

Commit Object
Tree Object
Blob Object
Trust
Tag Object
How Git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption

The index

8. Submodules

Pitfalls with submodules

9. Low-level Git operations

Object access and manipulation

The Workflow

working directory → index
index → object database
object database → index
index → working directory
Tying it all together

Examining the data

Merging multiple trees

Merging multiple trees, continued

10. Hacking Git

Object storage format
A birds-eye view of Git’s source code

11. Git Glossary

Git explained

A. Git Quick Reference

Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance

B. Notes and todo list for this manual

Todo list

Introduction

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX +Git User Manual

Git User Manual

Revision History
	2024-03-21

Table of Contents

Introduction

1. Repositories and Branches

How to get a Git repository

How to check out a different version of a project

Understanding History: Commits

Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?

Manipulating branches

Examining an old version without creating a new branch

Examining branches from a remote repository

Naming branches, tags, and other references

Updating a repository with git fetch

Fetching branches from other repositories

2. Exploring Git history

How to use bisect to find a regression

Naming commits

Creating tags

Browsing revisions

Generating diffs

Viewing old file versions

Examples

Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content

3. Developing with Git

Telling Git your name

Creating a new repository

How to make a commit

Creating good commit messages

Ignoring files

How to merge

Resolving a merge

Getting conflict-resolution help during a merge

Undoing a merge

Fast-forward merges

Fixing mistakes

Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress

Ensuring good performance

Ensuring reliability

Checking the repository for corruption
Recovering lost changes

4. Sharing development with others

Getting updates with git pull

Submitting patches to a project

Importing patches to a project

Public Git repositories

Setting up a public repository
Exporting a Git repository via the Git protocol
Exporting a git repository via HTTP
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository

How to get a Git repository with minimal history

Examples

Maintaining topic branches for a Linux subsystem maintainer

5. Rewriting history and maintaining patch series

Creating the perfect patch series
Keeping a patch series up to date using git rebase
Rewriting a single commit
Reordering or selecting from a patch series
Using interactive rebases
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history

6. Advanced branch management

Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote-tracking branches

7. Git concepts

The Object Database

Commit Object
Tree Object
Blob Object
Trust
Tag Object
How Git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption

The index

8. Submodules

Pitfalls with submodules

9. Low-level Git operations

Object access and manipulation

The Workflow

working directory → index
index → object database
object database → index
index → working directory
Tying it all together

Examining the data

Merging multiple trees

Merging multiple trees, continued

10. Hacking Git

Object storage format
A birds-eye view of Git’s source code

11. Git Glossary

Git explained

A. Git Quick Reference

Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance

B. Notes and todo list for this manual

Todo list

Introduction

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of Git.

Chapter 1, Repositories and Branches and Chapter 2, Exploring Git history explain how to fetch and study a project using git—read these chapters to learn how to build and test a particular version of a software project, search for @@ -1858,7 +1858,18 @@ that not only specifies their type, but also provides size information about the data in the object. It’s worth noting that the SHA-1 hash that is used to name the object is the hash of the original data plus this header, so sha1sum file does not match the object name -for file.

As a result, the general consistency of an object can always be tested +for file (the earliest versions of Git hashed slightly differently +but the conclusion is still the same).

The following is a short example that demonstrates how these hashes +can be generated manually:

Let’s assume a small text file with some simple content:

$ echo "Hello world" >hello.txt

We can now manually generate the hash Git would use for this file:

+The object we want the hash for is of type "blob" and its size is + 12 bytes. +
+Prepend the object header to the file content and feed this to + sha1sum: +

$ { printf "blob 12\0"; cat hello.txt; } | sha1sum
+802992c4220de19a90767f3000a79a31b98d0df7  -

This manually constructed hash can be verified using git hash-object +which of course hides the addition of the header:

$ git hash-object hello.txt
+802992c4220de19a90767f3000a79a31b98d0df7

As a result, the general consistency of an object can always be tested independently of the contents or the type of the object: all objects can be validated by verifying that (a) their hashes match the content of the file and (b) the object successfully inflates to a stream of bytes that @@ -1871,7 +1882,8 @@ of all objects, and verifies their internal consistency (in addition to just verifying their superficial consistency through the hash).

A birds-eye view of Git’s source code

It is not always easy for new developers to find their way through Git’s source code. This section gives you a little guidance to show where to start.

A good place to start is with the contents of the initial commit, with:

$ git switch --detach e83c5163

The initial revision lays the foundation for almost everything Git has -today, but is small enough to read in one sitting.

Note that terminology has changed since that revision. For example, the +today (even though details may differ in a few places), but is small +enough to read in one sitting.

Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we now call a commit.

Also, we do not call it "cache" any more, but rather "index"; however, the file is still called read-cache.h.

If you grasp the ideas in that initial commit, you should check out a diff --git a/user-manual.txt b/user-manual.txt index 643390349..90a418935 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -4093,7 +4093,38 @@ that not only specifies their type, but also provides size information about the data in the object. It's worth noting that the SHA-1 hash that is used to name the object is the hash of the original data plus this header, so `sha1sum` 'file' does not match the object name -for 'file'. +for 'file' (the earliest versions of Git hashed slightly differently +but the conclusion is still the same). + +The following is a short example that demonstrates how these hashes +can be generated manually: + +Let's assume a small text file with some simple content: + +------------------------------------------------- +$ echo "Hello world" >hello.txt +------------------------------------------------- + +We can now manually generate the hash Git would use for this file: + +- The object we want the hash for is of type "blob" and its size is + 12 bytes. + +- Prepend the object header to the file content and feed this to + `sha1sum`: + +------------------------------------------------- +$ { printf "blob 12\0"; cat hello.txt; } | sha1sum +802992c4220de19a90767f3000a79a31b98d0df7 - +------------------------------------------------- + +This manually constructed hash can be verified using `git hash-object` +which of course hides the addition of the header: + +------------------------------------------------- +$ git hash-object hello.txt +802992c4220de19a90767f3000a79a31b98d0df7 +------------------------------------------------- As a result, the general consistency of an object can always be tested independently of the contents or the type of the object: all objects can @@ -4123,7 +4154,8 @@ $ git switch --detach e83c5163 ---------------------------------------------------- The initial revision lays the foundation for almost everything Git has -today, but is small enough to read in one sitting. +today (even though details may differ in a few places), but is small +enough to read in one sitting. Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we -- cgit 1.2.3-korg

My First Contribution to the Git Project

My First Object Walk

Reviewing Patches in the Git Project

Submitting Patches

Tools for developing Git

Everyday Git With 20 Commands Or So

git-remote-helpers

Keep authoritative canonical history correct with git pull

How to maintain Git

How to integrate new subcommands

How to rebase from an internal branch

How to rebuild from update hook

How to recover a corrupted blob object

How to recover an object from scratch

How to revert a faulty merge

How to revert an existing commit

How to separate topic branches

How to setup Git server over http

How to use the update hook

How to use git-daemon

How to use the subtree merge strategy

How to use a signed tag in pull requests

Error reporting in git

Git API Documents

merge API

parse-options API

Simple-IPC API

Trace2 API

GIT bitmap v1 format

Bundle URIs

Git hash function transition

Long-running process protocol

Multi-Pack-Index (MIDX) Design Notes

Concerning Git’s Packing Heuristics

Parallel Checkout Design Notes

Partial Clone Design Notes

Use of index and Racy Git problem

Scalar

Git-send-pack internals

Shallow commits

Trivial merge rules

Unit Testing

Git User Manual

Introduction

Git User Manual

Introduction

A birds-eye view of Git’s source code