+MAN5_TXT += gitformat-bundle.txt

+MAN5_TXT += gitformat-chunk.txt

+MAN5_TXT += gitformat-commit-graph.txt

+MAN5_TXT += gitformat-index.txt

+MAN5_TXT += gitformat-pack.txt

+MAN5_TXT += gitformat-signature.txt

+MAN5_TXT += gitprotocol-capabilities.txt

+MAN5_TXT += gitprotocol-common.txt

+MAN5_TXT += gitprotocol-http.txt

+MAN5_TXT += gitprotocol-pack.txt

+MAN5_TXT += gitprotocol-v2.txt

+TECH_DOCS += technical/bundle-uri

+ cmds-developerinterfaces.txt \

+ cmds-userinterfaces.txt \

+ * "git symbolic-ref symref non..sen..se" is now diagnosed as an error.

+ (merge 04ede97211 lt/symbolic-ref-sanity later to maint).

+

+ * A follow-up fix to a fix for a regression in 2.36.

+ (merge 99ddc24672 ab/hooks-regression-fix later to maint).

+

+ * Avoid repeatedly running getconf to ask libc version in the test

+ suite, and instead just as it once per script.

+ (merge a6a58f7801 pw/use-glibc-tunable-for-malloc-optim later to maint).

+

+ * Platform-specific code that determines if a directory is OK to use

+ as a repository has been taught to report more details, especially

+ on Windows.

+ (merge 3f7207e2ea js/safe-directory-plus later to maint).

+

+ (merge 94955d576b gc/git-reflog-doc-markup later to maint).

+ linkgit:gitprotocol-v2[5]) and will advertise support for this feature during the

+ linkgit:gitformat-pack[5])

+* `2` - Wire protocol version 2, see linkgit:gitprotocol-v2[5].

+ This option implies `-u`. Lone CR characters are untouched, thus

+ while a CRLF cleans to LF, a CRCRLF sequence is only partially

+ cleaned to CRLF.

+include::rerere-options.txt[]

+See linkgit:gitformat-bundle[5] for more details and the discussion of

+"thin pack" in linkgit:gitformat-pack[5] for further details.

+ filter", is printed. See "Capabilities" in linkgit:gitformat-bundle[5]

+FILE FORMAT

+-----------

+

+See linkgit:gitformat-bundle[5].

+

+include::rerere-options.txt[]

+FILE FORMAT

+-----------

+

+see linkgit:gitformat-commit-graph[5].

+

+'git help' [[-i|--info] [-m|--man] [-w|--web]] [<command>|<doc>]

+'git help' [--user-interfaces]

+'git help' [--developer-interfaces]

+With no options and no '<command>' or '<doc>' given, the synopsis of the 'git'

+If a command or other documentation is given, the relevant manual page

+will be brought up. The 'man' program is used by default for this

+--user-interfaces::

+ Prints a list of the repository, command and file interfaces

+ documentation on the standard output.

++

+In-repository file interfaces such as `.git/info/exclude` are

+documented here (see linkgit:gitrepository-layout[5]), as well as

+in-tree configuration such as `.mailmap` (see linkgit:gitmailmap[5]).

++

+This section of the documentation also covers general or widespread

+user-interface conventions (e.g. linkgit:gitcli[7]), and

+pseudo-configuration such as the file-based `.git/hooks/*` interface

+described in linkgit:githooks[5].

+

+--developer-interfaces::

+ Print list of file formats, protocols and other developer

+ interfaces documentation on the standard output.

+

+include::rerere-options.txt[]

+Document] and linkgit:gitformat-pack[5] for more information on the

+multi-pack-index feature and its file format.

+include::rerere-options.txt[]

+ [--dry-run | -n] [--verbose] <ref>@{<specifier>}...

+include::rerere-options.txt[]

+ "Smart Clients" in linkgit:gitprotocol-http[5] and "HTTP

+ Transport" in in the linkgit:gitprotocol-v2[5]

+ documentation. Also understood by

+Repository, command and file interfaces

+---------------------------------------

+

+This documentation discusses repository and command interfaces which

+users are expected to interact with directly. See `--user-formats` in

+linkgit:git-help[1] for more details on the critera.

+

+include::cmds-userinterfaces.txt[]

+

+File formats, protocols and other developer interfaces

+------------------------------------------------------

+

+This documentation discusses file formats, over-the-wire protocols and

+other git developer interfaces. See `--developer-interfaces` in

+linkgit:git-help[1].

+

+include::cmds-developerinterfaces.txt[]

+gitformat-bundle(5)

+===================

+NAME

+----

+gitformat-bundle - The bundle file format

+

+

+SYNOPSIS

+--------

+[verse]

+*.bundle

+*.bdl

+

+DESCRIPTION

+-----------

+

+The Git bundle format is a format that represents both refs and Git

+objects. A bundle is a header in a format similar to

+linkgit:git-show-ref[1] followed by a pack in *.pack format.

+The format is created and read by the linkgit:git-bundle[1] command,

+and supported by e.g. linkgit:git-fetch[1] and linkgit:git-clone[1].

+

+

+FORMAT

+------

+linkgit:gitprotocol-common[5] for the details.

+

+SEMANTICS

+---------

+Note on the shallow clone and a Git bundle

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+CAPABILITIES

+------------

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitformat-chunk(5)

+==================

+

+NAME

+----

+gitformat-chunk - Chunk-based file formats

+

+SYNOPSIS

+--------

+

+Used by linkgit:gitformat-commit-graph[5] and the "MIDX" format (see

+the pack format documentation in linkgit:gitformat-pack[5]).

+

+DESCRIPTION

+-----------

+the `multi-pack-index` format in linkgit:gitformat-pack[5] and

+the `commit-graph` format in linkgit:gitformat-commit-graph[5] for

+ the commit-graph file format in linkgit:gitformat-commit-graph[5].

+ the multi-pack-index file format section of linkgit:gitformat-pack[5].

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitformat-commit-graph(5)

+=========================

+

+NAME

+----

+gitformat-commit-graph - Git commit graph format

+

+SYNOPSIS

+--------

+[verse]

+$GIT_DIR/objects/info/commit-graph

+$GIT_DIR/objects/info/commit-graphs/*

+

+DESCRIPTION

+-----------

+=== HEADER:

+=== CHUNK LOOKUP:

+ the chunk-based file format, see linkgit:gitformat-chunk[5]

+=== CHUNK DATA:

+==== OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes)

+==== OID Lookup (ID: {'O', 'I', 'D', 'L'}) (N * H bytes)

+==== Commit Data (ID: {'C', 'D', 'A', 'T' }) (N * (H + 16) bytes)

+==== Generation Data (ID: {'G', 'D', 'A', '2' }) (N * 4 bytes) [Optional]

+==== Generation Data Overflow (ID: {'G', 'D', 'O', '2' }) [Optional]

+==== Extra Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional]

+==== Bloom Filter Index (ID: {'B', 'I', 'D', 'X'}) (N * 4 bytes) [Optional]

+==== Bloom Filter Data (ID: {'B', 'D', 'A', 'T'}) [Optional]

+==== Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional]

+=== TRAILER:

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitformat-index(5)

+==================

+

+NAME

+----

+gitformat-index - Git index format

+

+SYNOPSIS

+--------

+[verse]

+$GIT_DIR/index

+

+DESCRIPTION

+-----------

+

+ for OFS_DELTA pack entries; see linkgit:gitformat-pack[5]) is stored, followed

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitformat-pack(5)

+=================

+

+NAME

+----

+gitformat-pack - Git pack format

+

+

+SYNOPSIS

+--------

+[verse]

+$GIT_DIR/objects/pack/pack-*.{pack,idx}

+$GIT_DIR/objects/pack/pack-*.rev

+$GIT_DIR/objects/pack/pack-*.mtimes

+$GIT_DIR/objects/pack/multi-pack-index

+

+DESCRIPTION

+-----------

+

+The Git pack format is now Git stores most of its primary repository

+data. Over the lietime af a repository loose objects (if any) and

+smaller packs are consolidated into larger pack(s). See

+linkgit:git-gc[1] and linkgit:git-pack-objects[1].

+

+The pack format is also used over-the-wire, see

+e.g. linkgit:gitprotocol-v2[5], as well as being a part of

+other container formats in the case of linkgit:gitformat-bundle[5].

+ the chunk-based file format, see linkgit:gitformat-chunk[5].

+

+== cruft packs

+

+The cruft packs feature offer an alternative to Git's traditional mechanism of

+removing unreachable objects. This document provides an overview of Git's

+pruning mechanism, and how a cruft pack can be used instead to accomplish the

+same.

+

+=== Background

+

+To remove unreachable objects from your repository, Git offers `git repack -Ad`

+(see linkgit:git-repack[1]). Quoting from the documentation:

+

+----

+[...] unreachable objects in a previous pack become loose, unpacked objects,

+instead of being left in the old pack. [...] loose unreachable objects will be

+pruned according to normal expiry rules with the next 'git gc' invocation.

+----

+

+Unreachable objects aren't removed immediately, since doing so could race with

+an incoming push which may reference an object which is about to be deleted.

+Instead, those unreachable objects are stored as loose objects and stay that way

+until they are older than the expiration window, at which point they are removed

+by linkgit:git-prune[1].

+

+Git must store these unreachable objects loose in order to keep track of their

+per-object mtimes. If these unreachable objects were written into one big pack,

+then either freshening that pack (because an object contained within it was

+re-written) or creating a new pack of unreachable objects would cause the pack's

+mtime to get updated, and the objects within it would never leave the expiration

+window. Instead, objects are stored loose in order to keep track of the

+individual object mtimes and avoid a situation where all cruft objects are

+freshened at once.

+

+This can lead to undesirable situations when a repository contains many

+unreachable objects which have not yet left the grace period. Having large

+directories in the shards of `.git/objects` can lead to decreased performance in

+the repository. But given enough unreachable objects, this can lead to inode

+starvation and degrade the performance of the whole system. Since we

+can never pack those objects, these repositories often take up a large amount of

+disk space, since we can only zlib compress them, but not store them in delta

+chains.

+

+=== Cruft packs

+

+A cruft pack eliminates the need for storing unreachable objects in a loose

+state by including the per-object mtimes in a separate file alongside a single

+pack containing all loose objects.

+

+A cruft pack is written by `git repack --cruft` when generating a new pack.

+linkgit:git-pack-objects[1]'s `--cruft` option. Note that `git repack --cruft`

+is a classic all-into-one repack, meaning that everything in the resulting pack is

+reachable, and everything else is unreachable. Once written, the `--cruft`

+option instructs `git repack` to generate another pack containing only objects

+not packed in the previous step (which equates to packing all unreachable

+objects together). This progresses as follows:

+

+ 1. Enumerate every object, marking any object which is (a) not contained in a

+ kept-pack, and (b) whose mtime is within the grace period as a traversal

+ tip.

+

+ 2. Perform a reachability traversal based on the tips gathered in the previous

+ step, adding every object along the way to the pack.

+

+ 3. Write the pack out, along with a `.mtimes` file that records the per-object

+ timestamps.

+

+This mode is invoked internally by linkgit:git-repack[1] when instructed to

+write a cruft pack. Crucially, the set of in-core kept packs is exactly the set

+of packs which will not be deleted by the repack; in other words, they contain

+all of the repository's reachable objects.

+

+When a repository already has a cruft pack, `git repack --cruft` typically only

+adds objects to it. An exception to this is when `git repack` is given the

+`--cruft-expiration` option, which allows the generated cruft pack to omit

+expired objects instead of waiting for linkgit:git-gc[1] to expire those objects

+later on.

+

+It is linkgit:git-gc[1] that is typically responsible for removing expired

+unreachable objects.

+

+=== Caution for mixed-version environments

+

+Repositories that have cruft packs in them will continue to work with any older

+version of Git. Note, however, that previous versions of Git which do not

+understand the `.mtimes` file will use the cruft pack's mtime as the mtime for

+all of the objects in it. In other words, do not expect older (pre-cruft pack)

+versions of Git to interpret or even read the contents of the `.mtimes` file.

+

+Note that having mixed versions of Git GC-ing the same repository can lead to

+unreachable objects never being completely pruned. This can happen under the

+following circumstances:

+

+ - An older version of Git running GC explodes the contents of an existing

+ cruft pack loose, using the cruft pack's mtime.

+ - A newer version running GC collects those loose objects into a cruft pack,

+ where the .mtime file reflects the loose object's actual mtimes, but the

+ cruft pack mtime is "now".

+

+Repeating this process will lead to unreachable objects not getting pruned as a

+result of repeatedly resetting the objects' mtimes to the present time.

+

+If you are GC-ing repositories in a mixed version environment, consider omitting

+the `--cruft` option when using linkgit:git-repack[1] and linkgit:git-gc[1], and

+leaving the `gc.cruftPacks` configuration unset until all writers understand

+cruft packs.

+

+=== Alternatives

+

+Notable alternatives to this design include:

+

+ - The location of the per-object mtime data, and

+ - Storing unreachable objects in multiple cruft packs.

+

+On the location of mtime data, a new auxiliary file tied to the pack was chosen

+to avoid complicating the `.idx` format. If the `.idx` format were ever to gain

+support for optional chunks of data, it may make sense to consolidate the

+`.mtimes` format into the `.idx` itself.

+

+Storing unreachable objects among multiple cruft packs (e.g., creating a new

+cruft pack during each repacking operation including only unreachable objects

+which aren't already stored in an earlier cruft pack) is significantly more

+complicated to construct, and so aren't pursued here. The obvious drawback to

+the current implementation is that the entire cruft pack must be re-written from

+scratch.

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitformat-signature(5)

+======================

+NAME

+----

+gitformat-signature - Git cryptographic signature formats

+

+SYNOPSIS

+--------

+[verse]

+<[tag|commit] object header(s)>

+<over-the-wire protocol>

+

+DESCRIPTION

+-----------

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitprotocol-capabilities(5)

+===========================

+

+NAME

+----

+gitprotocol-capabilities - Protocol v0 and v1 capabilities

+

+SYNOPSIS

+--------

+[verse]

+<over-the-wire-protocol>

+

+DESCRIPTION

+-----------

+protocol. For version 2, please refer to the linkgit:gitprotocol-v2[5]

+understand the server's in-memory state. See linkgit:gitprotocol-pack[5],

+successful, it will send back an error message. See linkgit:gitprotocol-pack[5]

+'report-status' cannot report for such case. See linkgit:gitprotocol-pack[5]

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitprotocol-common(5)

+=====================

+

+NAME

+----

+gitprotocol-common - Things common to various protocols

+

+SYNOPSIS

+--------

+[verse]

+<over-the-wire-protocol>

+

+DESCRIPTION

+-----------

+

+This document sets defines things common to various over-the-wire

+protocols and file formats used in Git.

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitprotocol-http(5)

+===================

+

+NAME

+----

+gitprotocol-http - Git HTTP-based protocols

+

+

+SYNOPSIS

+--------

+[verse]

+<over-the-wire-protocol>

+

+

+DESCRIPTION

+-----------

+linkgit:gitprotocol-pack[5]) as a colon-separated string

+REFERENCES

+

+SEE ALSO

+--------

+

+linkgit:gitprotocol-pack[5]

+linkgit:gitprotocol-capabilities[5]

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitprotocol-pack(5)

+===================

+

+NAME

+----

+gitprotocol-pack - How packs are transferred over-the-wire

+

+SYNOPSIS

+--------

+[verse]

+<over-the-wire-protocol>

+

+DESCRIPTION

+-----------

+protocol to transfer data. http is documented in linkgit:gitprotocol-http[5].

+linkgit:gitprotocol-common[5]. When the grammar indicate `PKT-LINE(...)`, unless

+"version" with a value of '1' or '2'. See linkgit:gitprotocol-v2[5] for more

+See linkgit:gitformat-pack[5] for what the packfile itself actually looks like.

+

+GIT

+---

+Part of the linkgit:git[1] suite

+gitprotocol-v2(5)

+=================

+

+NAME

+----

+gitprotocol-v2 - Git Wire Protocol, Version 2

+

+SYNOPSIS

+--------

+[verse]

+<over-the-wire-protocol>

+

+DESCRIPTION

+-----------

+linkgit:gitprotocol-pack[5] and linkgit:gitprotocol-common[5] for more information.

+found in linkgit:gitprotocol-pack[5] and linkgit:gitprotocol-http[5], as well as the

+info/refs request as described in linkgit:gitprotocol-http[5] and requests that

+

+GIT

+---

+Part of the linkgit:git[1] suite

+linkgit:gitformat-pack[5]),

+ 'FILE FORMAT' => {

+ order => $order++,

+ },

+--rerere-autoupdate::

+--no-rerere-autoupdate::

+ After the rerere mechanism reuses a recorded resolution on

+ the current conflict to update the files in the working

+ tree, allow it to also update the index with the result of

+ resolution. `--no-rerere-autoupdate` is a good way to

+ double-check what `rerere` did and catch potential

+ mismerges, before committing the result to the index with a

+ separate `git add`.

+The pkt-line routines (linkgit:gitprotocol-common[5])

+Bundle URIs

+===========

+

+Git bundles are files that store a pack-file along with some extra metadata,

+including a set of refs and a (possibly empty) set of necessary commits. See

+linkgit:git-bundle[1] and link:bundle-format.txt[the bundle format] for more

+information.

+

+Bundle URIs are locations where Git can download one or more bundles in

+order to bootstrap the object database in advance of fetching the remaining

+objects from a remote.

+

+One goal is to speed up clones and fetches for users with poor network

+connectivity to the origin server. Another benefit is to allow heavy users,

+such as CI build farms, to use local resources for the majority of Git data

+and thereby reducing the load on the origin server.

+

+To enable the bundle URI feature, users can specify a bundle URI using

+command-line options or the origin server can advertise one or more URIs

+via a protocol v2 capability.

+

+Design Goals

+------------

+

+The bundle URI standard aims to be flexible enough to satisfy multiple

+workloads. The bundle provider and the Git client have several choices in

+how they create and consume bundle URIs.

+

+* Bundles can have whatever name the server desires. This name could refer

+ to immutable data by using a hash of the bundle contents. However, this

+ means that a new URI will be needed after every update of the content.

+ This might be acceptable if the server is advertising the URI (and the

+ server is aware of new bundles being generated) but would not be

+ ergonomic for users using the command line option.

+

+* The bundles could be organized specifically for bootstrapping full

+ clones, but could also be organized with the intention of bootstrapping

+ incremental fetches. The bundle provider must decide on one of several

+ organization schemes to minimize client downloads during incremental

+ fetches, but the Git client can also choose whether to use bundles for

+ either of these operations.

+

+* The bundle provider can choose to support full clones, partial clones,

+ or both. The client can detect which bundles are appropriate for the

+ repository's partial clone filter, if any.

+

+* The bundle provider can use a single bundle (for clones only), or a

+ list of bundles. When using a list of bundles, the provider can specify

+ whether or not the client needs _all_ of the bundle URIs for a full

+ clone, or if _any_ one of the bundle URIs is sufficient. This allows the

+ bundle provider to use different URIs for different geographies.

+

+* The bundle provider can organize the bundles using heuristics, such as

+ creation tokens, to help the client prevent downloading bundles it does

+ not need. When the bundle provider does not provide these heuristics,

+ the client can use optimizations to minimize how much of the data is

+ downloaded.

+

+* The bundle provider does not need to be associated with the Git server.

+ The client can choose to use the bundle provider without it being

+ advertised by the Git server.

+

+* The client can choose to discover bundle providers that are advertised

+ by the Git server. This could happen during `git clone`, during

+ `git fetch`, both, or neither. The user can choose which combination

+ works best for them.

+

+* The client can choose to configure a bundle provider manually at any

+ time. The client can also choose to specify a bundle provider manually

+ as a command-line option to `git clone`.

+

+Each repository is different and every Git server has different needs.

+Hopefully the bundle URI feature is flexible enough to satisfy all needs.

+If not, then the feature can be extended through its versioning mechanism.

+

+Server requirements

+-------------------

+

+To provide a server-side implementation of bundle servers, no other parts

+of the Git protocol are required. This allows server maintainers to use

+static content solutions such as CDNs in order to serve the bundle files.

+

+At the current scope of the bundle URI feature, all URIs are expected to

+be HTTP(S) URLs where content is downloaded to a local file using a `GET`

+request to that URL. The server could include authentication requirements

+to those requests with the aim of triggering the configured credential

+helper for secure access. (Future extensions could use "file://" URIs or

+SSH URIs.)

+

+Assuming a `200 OK` response from the server, the content at the URL is

+inspected. First, Git attempts to parse the file as a bundle file of

+version 2 or higher. If the file is not a bundle, then the file is parsed

+as a plain-text file using Git's config parser. The key-value pairs in

+that config file are expected to describe a list of bundle URIs. If

+neither of these parse attempts succeed, then Git will report an error to

+the user that the bundle URI provided erroneous data.

+

+Any other data provided by the server is considered erroneous.

+

+Bundle Lists

+------------

+

+The Git server can advertise bundle URIs using a set of `key=value` pairs.

+A bundle URI can also serve a plain-text file in the Git config format

+containing these same `key=value` pairs. In both cases, we consider this

+to be a _bundle list_. The pairs specify information about the bundles

+that the client can use to make decisions for which bundles to download

+and which to ignore.

+

+A few keys focus on properties of the list itself.

+

+bundle.version::

+ (Required) This value provides a version number for the bundle

+ list. If a future Git change enables a feature that needs the Git

+ client to react to a new key in the bundle list file, then this version

+ will increment. The only current version number is 1, and if any other

+ value is specified then Git will fail to use this file.

+

+bundle.mode::

+ (Required) This value has one of two values: `all` and `any`. When `all`

+ is specified, then the client should expect to need all of the listed

+ bundle URIs that match their repository's requirements. When `any` is

+ specified, then the client should expect that any one of the bundle URIs

+ that match their repository's requirements will suffice. Typically, the

+ `any` option is used to list a number of different bundle servers

+ located in different geographies.

+

+bundle.heuristic::

+ If this string-valued key exists, then the bundle list is designed to

+ work well with incremental `git fetch` commands. The heuristic signals

+ that there are additional keys available for each bundle that help

+ determine which subset of bundles the client should download. The only

+ heuristic currently planned is `creationToken`.

+

+The remaining keys include an `<id>` segment which is a server-designated

+name for each available bundle. The `<id>` must contain only alphanumeric

+and `-` characters.

+

+bundle.<id>.uri::

+ (Required) This string value is the URI for downloading bundle `<id>`.

+ If the URI begins with a protocol (`http://` or `https://`) then the URI

+ is absolute. Otherwise, the URI is interpreted as relative to the URI

+ used for the bundle list. If the URI begins with `/`, then that relative

+ path is relative to the domain name used for the bundle list. (This use

+ of relative paths is intended to make it easier to distribute a set of

+ bundles across a large number of servers or CDNs with different domain

+ names.)

+

+bundle.<id>.filter::

+ This string value represents an object filter that should also appear in

+ the header of this bundle. The server uses this value to differentiate

+ different kinds of bundles from which the client can choose those that

+ match their object filters.

+

+bundle.<id>.creationToken::

+ This value is a nonnegative 64-bit integer used for sorting the bundles

+ the list. This is used to download a subset of bundles during a fetch

+ when `bundle.heuristic=creationToken`.

+

+bundle.<id>.location::

+ This string value advertises a real-world location from where the bundle

+ URI is served. This can be used to present the user with an option for

+ which bundle URI to use or simply as an informative indicator of which

+ bundle URI was selected by Git. This is only valuable when

+ `bundle.mode` is `any`.

+

+Here is an example bundle list using the Git config format:

+

+ [bundle]

+ version = 1

+ mode = all

+ heuristic = creationToken

+

+ [bundle "2022-02-09-1644442601-daily"]

+ uri = https://bundles.example.com/git/git/2022-02-09-1644442601-daily.bundle

+ creationToken = 1644442601

+

+ [bundle "2022-02-02-1643842562"]

+ uri = https://bundles.example.com/git/git/2022-02-02-1643842562.bundle

+ creationToken = 1643842562

+

+ [bundle "2022-02-09-1644442631-daily-blobless"]

+ uri = 2022-02-09-1644442631-daily-blobless.bundle

+ creationToken = 1644442631

+ filter = blob:none

+

+ [bundle "2022-02-02-1643842568-blobless"]

+ uri = /git/git/2022-02-02-1643842568-blobless.bundle

+ creationToken = 1643842568

+ filter = blob:none

+

+This example uses `bundle.mode=all` as well as the

+`bundle.<id>.creationToken` heuristic. It also uses the `bundle.<id>.filter`

+options to present two parallel sets of bundles: one for full clones and

+another for blobless partial clones.

+

+Suppose that this bundle list was found at the URI

+`https://bundles.example.com/git/git/` and so the two blobless bundles have

+the following fully-expanded URIs:

+

+* `https://bundles.example.com/git/git/2022-02-09-1644442631-daily-blobless.bundle`

+* `https://bundles.example.com/git/git/2022-02-02-1643842568-blobless.bundle`

+

+Advertising Bundle URIs

+-----------------------

+

+If a user knows a bundle URI for the repository they are cloning, then

+they can specify that URI manually through a command-line option. However,

+a Git host may want to advertise bundle URIs during the clone operation,

+helping users unaware of the feature.

+

+The only thing required for this feature is that the server can advertise

+one or more bundle URIs. This advertisement takes the form of a new

+protocol v2 capability specifically for discovering bundle URIs.

+

+The client could choose an arbitrary bundle URI as an option _or_ select

+the URI with best performance by some exploratory checks. It is up to the

+bundle provider to decide if having multiple URIs is preferable to a

+single URI that is geodistributed through server-side infrastructure.

+

+Cloning with Bundle URIs

+------------------------

+

+The primary need for bundle URIs is to speed up clones. The Git client

+will interact with bundle URIs according to the following flow:

+

+1. The user specifies a bundle URI with the `--bundle-uri` command-line

+ option _or_ the client discovers a bundle list advertised by the

+ Git server.

+

+2. If the downloaded data from a bundle URI is a bundle, then the client

+ inspects the bundle headers to check that the prerequisite commit OIDs

+ are present in the client repository. If some are missing, then the

+ client delays unbundling until other bundles have been unbundled,

+ making those OIDs present. When all required OIDs are present, the

+ client unbundles that data using a refspec. The default refspec is

+ `+refs/heads/*:refs/bundles/*`, but this can be configured. These refs

+ are stored so that later `git fetch` negotiations can communicate the

+ bundled refs as `have`s, reducing the size of the fetch over the Git

+ protocol. To allow pruning refs from this ref namespace, Git may

+ introduce a numbered namespace (such as `refs/bundles/<i>/*`) such that

+ stale bundle refs can be deleted.

+

+3. If the file is instead a bundle list, then the client inspects the

+ `bundle.mode` to see if the list is of the `all` or `any` form.

+

+ a. If `bundle.mode=all`, then the client considers all bundle

+ URIs. The list is reduced based on the `bundle.<id>.filter` options

+ matching the client repository's partial clone filter. Then, all

+ bundle URIs are requested. If the `bundle.<id>.creationToken`

+ heuristic is provided, then the bundles are downloaded in decreasing

+ order by the creation token, stopping when a bundle has all required

+ OIDs. The bundles can then be unbundled in increasing creation token

+ order. The client stores the latest creation token as a heuristic

+ for avoiding future downloads if the bundle list does not advertise

+ bundles with larger creation tokens.

+

+ b. If `bundle.mode=any`, then the client can choose any one of the

+ bundle URIs to inspect. The client can use a variety of ways to

+ choose among these URIs. The client can also fallback to another URI

+ if the initial choice fails to return a result.

+

+Note that during a clone we expect that all bundles will be required, and

+heuristics such as `bundle.<uri>.creationToken` can be used to download

+bundles in chronological order or in parallel.

+

+If a given bundle URI is a bundle list with a `bundle.heuristic`

+value, then the client can choose to store that URI as its chosen bundle

+URI. The client can then navigate directly to that URI during later `git

+fetch` calls.

+

+When downloading bundle URIs, the client can choose to inspect the initial

+content before committing to downloading the entire content. This may

+provide enough information to determine if the URI is a bundle list or

+a bundle. In the case of a bundle, the client may inspect the bundle

+header to determine that all advertised tips are already in the client

+repository and cancel the remaining download.

+

+Fetching with Bundle URIs

+-------------------------

+

+When the client fetches new data, it can decide to fetch from bundle

+servers before fetching from the origin remote. This could be done via a

+command-line option, but it is more likely useful to use a config value

+such as the one specified during the clone.

+

+The fetch operation follows the same procedure to download bundles from a

+bundle list (although we do _not_ want to use parallel downloads here). We

+expect that the process will end when all prerequisite commit OIDs in a

+thin bundle are already in the object database.

+

+When using the `creationToken` heuristic, the client can avoid downloading

+any bundles if their creation tokenss are not larger than the stored

+creation token. After fetching new bundles, Git updates this local

+creation token.

+

+If the bundle provider does not provide a heuristic, then the client

+should attempt to inspect the bundle headers before downloading the full

+bundle data in case the bundle tips already exist in the client

+repository.

+

+Error Conditions

+----------------

+

+If the Git client discovers something unexpected while downloading

+information according to a bundle URI or the bundle list found at that

+location, then Git can ignore that data and continue as if it was not

+given a bundle URI. The remote Git server is the ultimate source of truth,

+not the bundle URI.

+

+Here are a few example error conditions:

+

+* The client fails to connect with a server at the given URI or a connection

+ is lost without any chance to recover.

+

+* The client receives a 400-level response (such as `404 Not Found` or

+ `401 Not Authorized`). The client should use the credential helper to

+ find and provide a credential for the URI, but match the semantics of

+ Git's other HTTP protocols in terms of handling specific 400-level

+ errors.

+

+* The server reports any other failure reponse.

+

+* The client receives data that is not parsable as a bundle or bundle list.

+

+* A bundle includes a filter that does not match expectations.

+

+* The client cannot unbundle the bundles because the prerequisite commit OIDs

+ are not in the object database and there are no more bundles to download.

+

+There are also situations that could be seen as wasteful, but are not

+error conditions:

+

+* The downloaded bundles contain more information than is requested by

+ the clone or fetch request. A primary example is if the user requests

+ a clone with `--single-branch` but downloads bundles that store every

+ reachable commit from all `refs/heads/*` references. This might be

+ initially wasteful, but perhaps these objects will become reachable by

+ a later ref update that the client cares about.

+

+* A bundle download during a `git fetch` contains objects already in the

+ object database. This is probably unavoidable if we are using bundles

+ for fetches, since the client will almost always be slightly ahead of

+ the bundle servers after performing its "catch-up" fetch to the remote

+ server. This extra work is most wasteful when the client is fetching

+ much more frequently than the server is computing bundles, such as if

+ the client is using hourly prefetches with background maintenance, but

+ the server is computing bundles weekly. For this reason, the client

+ should not use bundle URIs for fetch unless the server has explicitly

+ recommended it through a `bundle.heuristic` value.

+

+Example Bundle Provider organization

+------------------------------------

+

+The bundle URI feature is intentionally designed to be flexible to

+different ways a bundle provider wants to organize the object data.

+However, it can be helpful to have a complete organization model described

+here so providers can start from that base.

+

+This example organization is a simplified model of what is used by the

+GVFS Cache Servers (see section near the end of this document) which have

+been beneficial in speeding up clones and fetches for very large

+repositories, although using extra software outside of Git.

+

+The bundle provider deploys servers across multiple geographies. Each

+server manages its own bundle set. The server can track a number of Git

+repositories, but provides a bundle list for each based on a pattern. For

+example, when mirroring a repository at `https://<domain>/<org>/<repo>`

+the bundle server could have its bundle list available at

+`https://<server-url>/<domain>/<org>/<repo>`. The origin Git server can

+list all of these servers under the "any" mode:

+

+ [bundle]

+ version = 1

+ mode = any

+

+ [bundle "eastus"]

+ uri = https://eastus.example.com/<domain>/<org>/<repo>

+

+ [bundle "europe"]

+ uri = https://europe.example.com/<domain>/<org>/<repo>

+

+ [bundle "apac"]

+ uri = https://apac.example.com/<domain>/<org>/<repo>

+

+This "list of lists" is static and only changes if a bundle server is

+added or removed.

+

+Each bundle server manages its own set of bundles. The initial bundle list

+contains only a single bundle, containing all of the objects received from

+cloning the repository from the origin server. The list uses the

+`creationToken` heuristic and a `creationToken` is made for the bundle

+based on the server's timestamp.

+

+The bundle server runs regularly-scheduled updates for the bundle list,

+such as once a day. During this task, the server fetches the latest

+contents from the origin server and generates a bundle containing the

+objects reachable from the latest origin refs, but not contained in a

+previously-computed bundle. This bundle is added to the list, with care

+that the `creationToken` is strictly greater than the previous maximum

+`creationToken`.

+

+When the bundle list grows too large, say more than 30 bundles, then the

+oldest "_N_ minus 30" bundles are combined into a single bundle. This

+bundle's `creationToken` is equal to the maximum `creationToken` among the

+merged bundles.

+

+An example bundle list is provided here, although it only has two daily

+bundles and not a full list of 30:

+

+ [bundle]

+ version = 1

+ mode = all

+ heuristic = creationToken

+

+ [bundle "2022-02-13-1644770820-daily"]

+ uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644770820-daily.bundle

+ creationToken = 1644770820

+

+ [bundle "2022-02-09-1644442601-daily"]

+ uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644442601-daily.bundle

+ creationToken = 1644442601

+

+ [bundle "2022-02-02-1643842562"]

+ uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-02-1643842562.bundle

+ creationToken = 1643842562

+

+To avoid storing and serving object data in perpetuity despite becoming

+unreachable in the origin server, this bundle merge can be more careful.

+Instead of taking an absolute union of the old bundles, instead the bundle

+can be created by looking at the newer bundles and ensuring that their

+necessary commits are all available in this merged bundle (or in another

+one of the newer bundles). This allows "expiring" object data that is not

+being used by new commits in this window of time. That data could be

+reintroduced by a later push.

+

+The intention of this data organization has two main goals. First, initial

+clones of the repository become faster by downloading precomputed object

+data from a closer source. Second, `git fetch` commands can be faster,

+especially if the client has not fetched for a few days. However, if a

+client does not fetch for 30 days, then the bundle list organization would

+cause redownloading a large amount of object data.

+

+One way to make this organization more useful to users who fetch frequently

+is to have more frequent bundle creation. For example, bundles could be

+created every hour, and then once a day those "hourly" bundles could be

+merged into a "daily" bundle. The daily bundles are merged into the

+oldest bundle after 30 days.

+

+It is recommened that this bundle strategy is repeated with the `blob:none`

+filter if clients of this repository are expecting to use blobless partial

+clones. This list of blobless bundles stays in the same list as the full

+bundles, but uses the `bundle.<id>.filter` key to separate the two groups.

+For very large repositories, the bundle provider may want to _only_ provide

+blobless bundles.

+

+Implementation Plan

+-------------------

+

+This design document is being submitted on its own as an aspirational

+document, with the goal of implementing all of the mentioned client

+features over the course of several patch series. Here is a potential

+outline for submitting these features:

+

+1. Integrate bundle URIs into `git clone` with a `--bundle-uri` option.

+ This will include a new `git fetch --bundle-uri` mode for use as the

+ implementation underneath `git clone`. The initial version here will

+ expect a single bundle at the given URI.

+

+2. Implement the ability to parse a bundle list from a bundle URI and

+ update the `git fetch --bundle-uri` logic to properly distinguish

+ between `bundle.mode` options. Specifically design the feature so

+ that the config format parsing feeds a list of key-value pairs into the

+ bundle list logic.

+

+3. Create the `bundle-uri` protocol v2 command so Git servers can advertise

+ bundle URIs using the key-value pairs. Plug into the existing key-value

+ input to the bundle list logic. Allow `git clone` to discover these

+ bundle URIs and bootstrap the client repository from the bundle data.

+ (This choice is an opt-in via a config option and a command-line

+ option.)

+

+4. Allow the client to understand the `bundle.flag=forFetch` configuration

+ and the `bundle.<id>.creationToken` heuristic. When `git clone`

+ discovers a bundle URI with `bundle.flag=forFetch`, it configures the

+ client repository to check that bundle URI during later `git fetch <remote>`

+ commands.

+

+5. Allow clients to discover bundle URIs during `git fetch` and configure

+ a bundle URI for later fetches if `bundle.flag=forFetch`.

+

+6. Implement the "inspect headers" heuristic to reduce data downloads when

+ the `bundle.<id>.creationToken` heuristic is not available.

+

+As these features are reviewed, this plan might be updated. We also expect

+that new designs will be discovered and implemented as this feature

+matures and becomes used in real-world scenarios.

+

+Related Work: Packfile URIs

+---------------------------

+

+The Git protocol already has a capability where the Git server can list

+a set of URLs along with the packfile response when serving a client

+request. The client is then expected to download the packfiles at those

+locations in order to have a complete understanding of the response.

+

+This mechanism is used by the Gerrit server (implemented with JGit) and

+has been effective at reducing CPU load and improving user performance for

+clones.

+

+A major downside to this mechanism is that the origin server needs to know

+_exactly_ what is in those packfiles, and the packfiles need to be available

+to the user for some time after the server has responded. This coupling

+between the origin and the packfile data is difficult to manage.

+

+Further, this implementation is extremely hard to make work with fetches.

+

+Related Work: GVFS Cache Servers

+--------------------------------

+

+The GVFS Protocol [2] is a set of HTTP endpoints designed independently of

+the Git project before Git's partial clone was created. One feature of this

+protocol is the idea of a "cache server" which can be colocated with build

+machines or developer offices to transfer Git data without overloading the

+central server.

+

+The endpoint that VFS for Git is famous for is the `GET /gvfs/objects/{oid}`

+endpoint, which allows downloading an object on-demand. This is a critical

+piece of the filesystem virtualization of that product.

+

+However, a more subtle need is the `GET /gvfs/prefetch?lastPackTimestamp=<t>`

+endpoint. Given an optional timestamp, the cache server responds with a list

+of precomputed packfiles containing the commits and trees that were introduced

+in those time intervals.

+

+The cache server computes these "prefetch" packfiles using the following

+strategy:

+

+1. Every hour, an "hourly" pack is generated with a given timestamp.

+2. Nightly, the previous 24 hourly packs are rolled up into a "daily" pack.

+3. Nightly, all prefetch packs more than 30 days old are rolled up into

+ one pack.

+

+When a user runs `gvfs clone` or `scalar clone` against a repo with cache

+servers, the client requests all prefetch packfiles, which is at most

+`24 + 30 + 1` packfiles downloading only commits and trees. The client

+then follows with a request to the origin server for the references, and

+attempts to checkout that tip reference. (There is an extra endpoint that

+helps get all reachable trees from a given commit, in case that commit

+was not already in a prefetch packfile.)

+

+During a `git fetch`, a hook requests the prefetch endpoint using the

+most-recent timestamp from a previously-downloaded prefetch packfile.

+Only the list of packfiles with later timestamps are downloaded. Most

+users fetch hourly, so they get at most one hourly prefetch pack. Users

+whose machines have been off or otherwise have not fetched in over 30 days

+might redownload all prefetch packfiles. This is rare.

+

+It is important to note that the clients always contact the origin server

+for the refs advertisement, so the refs are frequently "ahead" of the

+prefetched pack data. The missing objects are downloaded on-demand using

+the `GET gvfs/objects/{oid}` requests, when needed by a command such as

+`git checkout` or `git log`. Some Git optimizations disable checks that

+would cause these on-demand downloads to be too aggressive.

+

+See Also

+--------

+

+[1] https://lore.kernel.org/git/RFC-cover-00.13-0000000000-20210805T150534Z-avarab@gmail.com/

+ An earlier RFC for a bundle URI feature.

+

+[2] https://github.com/microsoft/VFSForGit/blob/master/Protocol.md

+ The GVFS Protocol

+format described in linkgit:gitformat-pack[5], just like

+communication is in pkt-line format (see linkgit:gitprotocol-common[5])

+(e.g. ofs-delta and thin-pack). See linkgit:gitprotocol-v2[5] for the documentation of

+See "filter" in linkgit:gitprotocol-pack[5].

+found in link:gitformat-pack[5].

+ -e '/interfaces$$/d' \

+ struct strvec *rev_argv,

+ struct setup_revision_opt opt = {

+ .free_removed_argv_elements = 1,

+ };

+ strvec_push(rev_argv, "bisect_rev_setup");

+ strvec_pushf(rev_argv, bad_format, oid_to_hex(current_bad_oid));

+ strvec_pushf(rev_argv, good_format,

+ strvec_push(rev_argv, "--");

+ read_bisect_paths(rev_argv);

+ setup_revisions(rev_argv->nr, rev_argv->v, revs, &opt);

+ struct strvec rev_argv = STRVEC_INIT;

+ bisect_rev_setup(r, &revs, &rev_argv, prefix, "^%s", "%s", 0);

+ strvec_clear(&rev_argv);

+ struct strvec rev_argv = STRVEC_INIT;

+ bisect_rev_setup(r, &revs, &rev_argv, prefix, "%s", "^%s", 1);

+ goto cleanup;

+ strvec_clear(&rev_argv);

+ rev.diffopt.flags.recursive = 1;

+ HELP_ACTION_USER_INTERFACES,

+ HELP_ACTION_DEVELOPER_INTERFACES,

+ OPT_CMDMODE(0, "user-interfaces", &cmd_mode,

+ N_("print list of user-facing repository, command and file interfaces"),

+ HELP_ACTION_USER_INTERFACES),

+ OPT_CMDMODE(0, "developer-interfaces", &cmd_mode,

+ N_("print list of file formats, protocols and other developer interfaces"),

+ HELP_ACTION_DEVELOPER_INTERFACES),

+ N_("git help [[-i|--info] [-m|--man] [-w|--web]] [<command>|<doc>]"),

+ "git help [--user-interfaces]",

+ "git help [--developer-interfaces]",

+ case HELP_ACTION_USER_INTERFACES:

+ opt_mode_usage(argc, "--user-interfaces", help_format);

+ list_user_interfaces_help();

+ return 0;

+ case HELP_ACTION_DEVELOPER_INTERFACES:

+ opt_mode_usage(argc, "--developer-interfaces", help_format);

+ list_developer_interfaces_help();

+ return 0;

+ unsigned int i;

+ int ret = 0;

+ for (i = 0; i < rev.pending.nr && !ret; i++) {

+ struct object *o = rev.pending.objects[i].item;

+ const char *name = rev.pending.objects[i].name;

+ rev.pending.objects[i].item = o;

+ {

+ struct object_array old;

+ struct object_array blank = OBJECT_ARRAY_INIT;

+

+ memcpy(&old, &rev.pending, sizeof(old));

+ memcpy(&rev.pending, &blank, sizeof(rev.pending));

+

+

+ /*

+ * No need for

+ * object_array_clear(&pending). It was

+ * cleared already in prepare_revision_walk()

+ */

+ memcpy(&rev.pending, &old, sizeof(rev.pending));

+ }

+ if (pathspec->nr && pathspec_needs_expanded_index(&the_index, pathspec))

+ prepare_repo_settings(the_repository);

+ the_repository->settings.command_requires_full_index = 0;

+ if (pathspec_needs_expanded_index(&the_index, &pathspec))

+ ensure_full_index(&the_index);

+

+ struct setup_revision_opt opt = {

+ .free_removed_argv_elements = 1,

+ };

+ setup_revisions(diff_args.nr, diff_args.v, &rev, &opt);

+ if (check_refname_format(argv[1], REFNAME_ALLOW_ONELEVEL) < 0)

+ die("Refusing to set '%s' to invalid ref '%s'", argv[0], argv[1]);

+ * of pack file format. See gitformat-pack(5) for more information.

+ * Like index_name_pos, returns the position of an entry of the given name in

+ * the index if one exists, otherwise returns a negative value where the negated

+ * value minus 1 is the position where the index entry would be inserted. Unlike

+ * index_name_pos, however, a sparse index is not expanded to find an entry

+ * inside a sparse directory.

+ */

+int index_name_pos_sparse(struct index_state *, const char *name, int namelen);

+

+/*

+ export GIT_TEST_SANITIZE_LEAK_LOG=true

+# User-facing repository, command and file interfaces such as

+# documentation for the .gitmodules, .mailmap etc. files lives in man

+# sections 5 and 7. These entries can only have the "userinterfaces"

+# attribute and nothing else.

+#

+# Git's file formats and protocols, such as documentation for the

+# *.bundle format lives in man section 5. These entries can only have

+# the "developerinterfaces" attribute and nothing else.

+#

+gitattributes userinterfaces

+gitcli userinterfaces

+gitformat-bundle developerinterfaces

+gitformat-chunk developerinterfaces

+gitformat-commit-graph developerinterfaces

+gitformat-index developerinterfaces

+gitformat-pack developerinterfaces

+gitformat-signature developerinterfaces

+githooks userinterfaces

+gitignore userinterfaces

+gitmailmap userinterfaces

+gitmodules userinterfaces

+gitprotocol-capabilities developerinterfaces

+gitprotocol-common developerinterfaces

+gitprotocol-http developerinterfaces

+gitprotocol-pack developerinterfaces

+gitprotocol-v2 developerinterfaces

+gitrepository-layout userinterfaces

+gitrevisions userinterfaces

+#include <sddl.h>

+static int acls_supported(const char *path)

+{

+ size_t offset = offset_1st_component(path);

+ WCHAR wroot[MAX_PATH];

+ DWORD file_system_flags;

+

+ if (offset &&

+ xutftowcsn(wroot, path, MAX_PATH, offset) > 0 &&

+ GetVolumeInformationW(wroot, NULL, 0, NULL, NULL,

+ &file_system_flags, NULL, 0))

+ return !!(file_system_flags & FILE_PERSISTENT_ACLS);

+

+ return 0;

+}

+

+int is_path_owned_by_current_sid(const char *path, struct strbuf *report)

+ BOOL is_member;

+ else if (IsWellKnownSid(sid, WinBuiltinAdministratorsSid) &&

+ CheckTokenMembership(NULL, sid, &is_member) &&

+ is_member)

+ /*

+ * If owned by the Administrators group, and the

+ * current user is an administrator, we consider that

+ * okay, too.

+ */

+ result = 1;

+ else if (report &&

+ IsWellKnownSid(sid, WinWorldSid) &&

+ !acls_supported(path)) {

+ /*

+ * On FAT32 volumes, ownership is not actually recorded.

+ */

+ strbuf_addf(report, "'%s' is on a file system that does"

+ "not record ownership\n", path);

+ } else if (report) {

+ LPSTR str1, str2, to_free1 = NULL, to_free2 = NULL;

+

+ if (ConvertSidToStringSidA(sid, &str1))

+ to_free1 = str1;

+ else

+ str1 = "(inconvertible)";

+

+ if (!current_user_sid)

+ str2 = "(none)";

+ else if (!IsValidSid(current_user_sid))

+ str2 = "(invalid)";

+ else if (ConvertSidToStringSidA(current_user_sid, &str2))

+ to_free2 = str2;

+ else

+ str2 = "(inconvertible)";

+ strbuf_addf(report,

+ "'%s' is owned by:\n"

+ "\t'%s'\nbut the current user is:\n"

+ "\t'%s'\n", path, str1, str2);

+ LocalFree(to_free1);

+ LocalFree(to_free2);

+ }

+int is_path_owned_by_current_sid(const char *path, struct strbuf *report);

+ . "$TEST_DIRECTORY"/lib-perl.sh

+ skip_all_if_no_Test_More

+ test_expect_success 'git-credential-netrc' '

+ '

+ $(RM) -r 'trash directory'.*

+ $(RM) -r 'trash directory'.*

+ if (S_ISSPARSEDIR(tree->ce_mode)) {

+ diff_tree_oid(&tree->oid, NULL, tree->name, &revs->diffopt);

+ return;

+ }

+

+ if (init_tree_desc_gently(&desc, tree->buffer, tree->size, 0))

+ if (init_tree_desc_gently(&desc, buffer, size, TREE_DESC_RAW_MODES)) {

+ FUNC(BAD_FILEMODE, INFO) \

+struct strbuf;

+

+

+static inline int is_path_owned_by_current_uid(const char *path, struct strbuf *report)

+ { CAT_userinterfaces, N_("User-facing repository, command and file interfaces") },

+ { CAT_developerinterfaces, N_("Developer-facing file file formats, protocols and interfaces") },

+ const char *prefix;

+

+ switch (category) {

+ case CAT_guide:

+ case CAT_userinterfaces:

+ case CAT_developerinterfaces:

+ prefix = "git";

+ break;

+ default:

+ prefix = "git-";

+ break;

+ }

+ if (skip_prefix(name, prefix, &new_name))

+ return name;

+void list_user_interfaces_help(void)

+{

+ struct category_description catdesc[] = {

+ { CAT_userinterfaces, N_("User-facing repository, command and file interfaces:") },

+ { 0, NULL }

+ };

+ print_cmd_by_category(catdesc, NULL);

+ putchar('\n');

+}

+

+void list_developer_interfaces_help(void)

+{

+ struct category_description catdesc[] = {

+ { CAT_developerinterfaces, N_("File formats, protocols and other developer interfaces:") },

+ { 0, NULL }

+ };

+ print_cmd_by_category(catdesc, NULL);

+ putchar('\n');

+}

+

+void list_user_interfaces_help(void);

+void list_developer_interfaces_help(void);

+ # Send message to stderr if global variable GIT_MERGETOOL_VIMDIFF_DEBUG

+ # is set.

+ # Search for all valid separators ("/" or ",") which are *not*

+ if test "$current" = "/"

+ if ! test -z "$index_horizontal_split"

+ CMD=

+ oldIFS=$IFS

+ IFS=+

+ for tab in $LAYOUT

+ do

+ if test -z "$CMD"

+ then

+ CMD="echo" # vim "nop" operator

+ else

+ CMD="$CMD | tabnew"

+ fi

+ # If this is a single window diff with all the buffers

+ if ! echo "$tab" | grep ",\|/" >/dev/null

+ then

+ CMD="$CMD | silent execute 'bufdo diffthis'"

+ fi

+ CMD=$(gen_cmd_aux "$tab" "$CMD")

+ done

+ IFS=$oldIFS

+ CMD="$CMD | execute 'tabdo windo diffthis'"

+ FINAL_CMD="-c \"set hidden diffopt-=hiddenoff | $CMD | tabfirst\""

+ EXPECTED_CMD_01="-c \"set hidden diffopt-=hiddenoff | echo | leftabove split | leftabove vertical split | 1b | wincmd l | leftabove vertical split | 2b | wincmd l | 3b | wincmd j | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_02="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | 1b | wincmd l | 3b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_03="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | 1b | wincmd l | leftabove vertical split | 4b | wincmd l | 3b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_04="-c \"set hidden diffopt-=hiddenoff | echo | silent execute 'bufdo diffthis' | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_05="-c \"set hidden diffopt-=hiddenoff | echo | leftabove split | 1b | wincmd j | leftabove split | 4b | wincmd j | 3b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_06="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | leftabove split | 1b | wincmd j | 3b | wincmd l | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_07="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | 4b | wincmd l | leftabove split | 1b | wincmd j | 3b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_08="-c \"set hidden diffopt-=hiddenoff | echo | leftabove split | leftabove vertical split | 1b | wincmd l | 3b | wincmd j | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_09="-c \"set hidden diffopt-=hiddenoff | echo | leftabove split | 4b | wincmd j | leftabove vertical split | 1b | wincmd l | 3b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_10="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | leftabove split | 1b | wincmd j | leftabove split | 2b | wincmd j | 3b | wincmd l | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_11="-c \"set hidden diffopt-=hiddenoff | echo | leftabove split | leftabove vertical split | 1b | wincmd l | leftabove vertical split | 2b | wincmd l | 3b | wincmd j | 4b | tabnew | leftabove vertical split | 2b | wincmd l | 1b | tabnew | leftabove vertical split | 2b | wincmd l | 3b | tabnew | leftabove vertical split | leftabove split | 1b | wincmd j | leftabove split | 2b | wincmd j | 3b | wincmd l | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_12="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | leftabove split | leftabove vertical split | 1b | wincmd l | 3b | wincmd j | 2b | wincmd l | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_13="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | leftabove split | leftabove vertical split | 1b | wincmd l | 3b | wincmd j | 2b | wincmd l | leftabove vertical split | leftabove split | 1b | wincmd j | 3b | wincmd l | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_14="-c \"set hidden diffopt-=hiddenoff | echo | leftabove vertical split | 2b | wincmd l | 3b | tabnew | leftabove vertical split | 2b | wincmd l | 1b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_15="-c \"set hidden diffopt-=hiddenoff | echo | leftabove split | leftabove vertical split | 1b | wincmd l | leftabove vertical split | 2b | wincmd l | 3b | wincmd j | 4b | tabnew | leftabove vertical split | 2b | wincmd l | 1b | tabnew | leftabove vertical split | 2b | wincmd l | 3b | tabnew | leftabove vertical split | leftabove split | 1b | wincmd j | leftabove split | 2b | wincmd j | 3b | wincmd l | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ EXPECTED_CMD_16="-c \"set hidden diffopt-=hiddenoff | echo | leftabove split | leftabove vertical split | 1b | wincmd l | leftabove vertical split | 2b | wincmd l | 3b | wincmd j | 4b | tabnew | leftabove vertical split | 2b | wincmd l | 1b | tabnew | leftabove vertical split | 2b | wincmd l | 3b | tabnew | leftabove vertical split | leftabove split | 1b | wincmd j | leftabove split | 2b | wincmd j | 3b | wincmd l | 4b | execute 'tabdo windo diffthis' | tabfirst\""

+ set hidden diffopt-=hiddenoff | echo | leftabove split | leftabove vertical split | 1b | wincmd l | leftabove vertical split | quit | wincmd l | 2b | wincmd j | 3b | execute 'tabdo windo diffthis' | tabfirst

+ * gitformat-pack(5).

+ if (init_tree_desc_gently(&desc, tree->buffer, tree->size, 0))

+

+int pathspec_needs_expanded_index(struct index_state *istate,

+ const struct pathspec *pathspec)

+{

+ unsigned int i, pos;

+ int res = 0;

+ char *skip_worktree_seen = NULL;

+

+ /*

+ * If index is not sparse, no index expansion is needed.

+ */

+ if (!istate->sparse_index)

+ return 0;

+

+ /*

+ * When using a magic pathspec, assume for the sake of simplicity that

+ * the index needs to be expanded to match all matchable files.

+ */

+ if (pathspec->magic)

+ return 1;

+

+ for (i = 0; i < pathspec->nr; i++) {

+ struct pathspec_item item = pathspec->items[i];

+

+ /*

+ * If the pathspec item has a wildcard, the index should be expanded

+ * if the pathspec has the possibility of matching a subset of entries inside

+ * of a sparse directory (but not the entire directory).

+ *

+ * If the pathspec item is a literal path, the index only needs to be expanded

+ * if a) the pathspec isn't in the sparse checkout cone (to make sure we don't

+ * expand for in-cone files) and b) it doesn't match any sparse directories

+ * (since we can reset whole sparse directories without expanding them).

+ */

+ if (item.nowildcard_len < item.len) {

+ /*

+ * Special case: if the pattern is a path inside the cone

+ * followed by only wildcards, the pattern cannot match

+ * partial sparse directories, so we know we don't need to

+ * expand the index.

+ *

+ * Examples:

+ * - in-cone/foo***: doesn't need expanded index

+ * - not-in-cone/bar*: may need expanded index

+ * - **.c: may need expanded index

+ */

+ if (strspn(item.original + item.nowildcard_len, "*") == item.len - item.nowildcard_len &&

+ path_in_cone_mode_sparse_checkout(item.original, istate))

+ continue;

+

+ for (pos = 0; pos < istate->cache_nr; pos++) {

+ struct cache_entry *ce = istate->cache[pos];

+

+ if (!S_ISSPARSEDIR(ce->ce_mode))

+ continue;

+

+ /*

+ * If the pre-wildcard length is longer than the sparse

+ * directory name and the sparse directory is the first

+ * component of the pathspec, need to expand the index.

+ */

+ if (item.nowildcard_len > ce_namelen(ce) &&

+ !strncmp(item.original, ce->name, ce_namelen(ce))) {

+ res = 1;

+ break;

+ }

+

+ /*

+ * If the pre-wildcard length is shorter than the sparse

+ * directory and the pathspec does not match the whole

+ * directory, need to expand the index.

+ */

+ if (!strncmp(item.original, ce->name, item.nowildcard_len) &&

+ wildmatch(item.original, ce->name, 0)) {

+ res = 1;

+ break;

+ }

+ }

+ } else if (!path_in_cone_mode_sparse_checkout(item.original, istate) &&

+ !matches_skip_worktree(pathspec, i, &skip_worktree_seen))

+ res = 1;

+

+ if (res > 0)

+ break;

+ }

+

+ free(skip_worktree_seen);

+ return res;

+}

+/*

+ * Determine whether a pathspec will match only entire index entries (non-sparse

+ * files and/or entire sparse directories). If the pathspec has the potential to

+ * match partial contents of a sparse directory, return 1 to indicate the index

+ * should be expanded to match the appropriate index entries.

+ *

+ * For the sake of simplicity, always return 1 if using a more complex "magic"

+ * pathspec.

+ */

+int pathspec_needs_expanded_index(struct index_state *istate,

+ const struct pathspec *pathspec);

+

+int index_name_pos_sparse(struct index_state *istate, const char *name, int namelen)

+{

+ return index_name_stage_pos(istate, name, namelen, 0, NO_EXPAND_SPARSE);

+}

+

+ * (see linkgit:gitprotocol-v2[5]).

+ struct setup_revision_opt opt = {

+ .free_removed_argv_elements = 1,

+ };

+ setup_revisions(argv.nr, argv.v, &revs, &opt);

+ if (opt && opt->free_removed_argv_elements)

+ free((char *)argv[i]);

+ allow_exclude_promisor_objects:1,

+ free_removed_argv_elements:1;

+ const char *worktree, const char *gitdir,

+ struct strbuf *report)

+ (!gitfile || is_path_owned_by_current_user(gitfile, report)) &&

+ (!worktree || is_path_owned_by_current_user(worktree, report)) &&

+ (!gitdir || is_path_owned_by_current_user(gitdir, report)))

+ struct strbuf *report,

+ const char *gitdir_candidate =

+ gitdir_path ? gitdir_path : gitdirenv;

+ if (ensure_valid_ownership(gitfile, dir->buf,

+ gitdir_candidate, report)) {

+ if (!ensure_valid_ownership(NULL, NULL, dir->buf, report))

+ if (setup_git_directory_gently_1(&dir, gitdir, NULL, 0) <= 0) {

+ struct strbuf dir = STRBUF_INIT, gitdir = STRBUF_INIT, report = STRBUF_INIT;

+ switch (setup_git_directory_gently_1(&dir, &gitdir, &report, 1)) {

+ strbuf_complete(&report, '\n');

+ "%s"

+ dir.buf, report.buf, quoted.buf);

+ strbuf_release(&report);

+ $(RM) -r 'trash directory'.*

+GIT_TEST_PASSING_SANITIZE_LEAK=true skips those tests that haven't

+declared themselves as leak-free by setting

+"TEST_PASSES_SANITIZE_LEAK=true" before sourcing "test-lib.sh". This

+test mode is used by the "linux-leaks" CI target.

+

+GIT_TEST_PASSING_SANITIZE_LEAK=check checks that our

+"TEST_PASSES_SANITIZE_LEAK=true" markings are current. Rather than

+skipping those tests that haven't set "TEST_PASSES_SANITIZE_LEAK=true"

+before sourcing "test-lib.sh" this mode runs them with

+"--invert-exit-code". This is used to check that there's a one-to-one

+mapping between "TEST_PASSES_SANITIZE_LEAK=true" and those tests that

+pass under "SANITIZE=leak". This is especially useful when testing a

+series that fixes various memory leaks with "git rebase -x".

+

+GIT_TEST_SANITIZE_LEAK_LOG=true will log memory leaks to

+"test-results/$TEST_NAME.leak/trace.*" files. The logs include a

+"dedup_token" (see +"ASAN_OPTIONS=help=1 ./git") and other options to

+make logs +machine-readable.

+

+With GIT_TEST_SANITIZE_LEAK_LOG=true we'll look at the leak logs

+before exiting and exit on failure if the logs showed that we had a

+memory leak, even if the test itself would have otherwise passed. This

+allows us to catch e.g. missing &&-chaining. This is especially useful

+when combined with "GIT_TEST_PASSING_SANITIZE_LEAK", see below.

+

+GIT_TEST_PASSING_SANITIZE_LEAK=check when combined with "--immediate"

+will run to completion faster, and result in the same failing

+tests. The only practical reason to run

+GIT_TEST_PASSING_SANITIZE_LEAK=check without "--immediate" is to

+combine it with "GIT_TEST_SANITIZE_LEAK_LOG=true". If we stop at the

+first failing test case our leak logs won't show subsequent leaks we

+might have run into.

+

+GIT_TEST_PASSING_SANITIZE_LEAK=(true|check) will not catch all memory

+leaks unless combined with GIT_TEST_SANITIZE_LEAK_LOG=true. Some tests

+run "git" (or "test-tool" etc.) without properly checking the exit

+code, or git will invoke itself and fail to ferry the abort() exit

+code to the original caller. When the two modes are combined we'll

+look at the "test-results/$TEST_NAME.leak/trace.*" files at the end of

+the test run to see if had memory leaks which the test itself didn't

+catch.

+# Copyright (c) 2022 Ævar Arnfjörð Bjarmason

+

+test_lazy_prereq PERL_TEST_MORE '

+ perl -MTest::More -e 0

+'

+

+skip_all_if_no_Test_More () {

+ if ! test_have_prereq PERL

+ then

+ skip_all='skipping perl interface tests, perl not available'

+ test_done

+ fi

+

+ if ! test_have_prereq PERL_TEST_MORE

+ then

+ skip_all="Perl Test::More unavailable, skipping test"

+ test_done

+ fi

+}

+test_perf_on_all "git rm -f $SPARSE_CONE/a && git checkout HEAD -- $SPARSE_CONE/a"

+test_expect_success 'subtest: --invert-exit-code without --immediate' '

+ run_sub_test_lib_test_err full-pass \

+ --invert-exit-code &&

+ check_sub_test_lib_test_err full-pass \

+ <<-\EOF_OUT 3<<-EOF_ERR

+ ok 1 - passing test #1

+ ok 2 - passing test #2

+ ok 3 - passing test #3

+ # passed all 3 test(s)

+ 1..3

+ # faking up non-zero exit with --invert-exit-code

+ EOF_OUT

+ EOF_ERR

+'

+

+test_expect_success 'subtest: --invert-exit-code with --immediate: all passed' '

+ run_sub_test_lib_test_err full-pass \

+ --invert-exit-code --immediate &&

+ check_sub_test_lib_test_err full-pass \

+ <<-\EOF_OUT 3<<-EOF_ERR

+ ok 1 - passing test #1

+ ok 2 - passing test #2

+ ok 3 - passing test #3

+ # passed all 3 test(s)

+ 1..3

+ # faking up non-zero exit with --invert-exit-code

+ EOF_OUT

+ EOF_ERR

+'

+

+test_expect_success 'subtest: --invert-exit-code without --immediate: partial pass' '

+ run_sub_test_lib_test partial-pass \

+ --invert-exit-code &&

+ check_sub_test_lib_test partial-pass <<-\EOF

+ ok 1 - passing test #1

+ not ok 2 - # TODO induced breakage (--invert-exit-code): failing test #2

+ # false

+ ok 3 - passing test #3

+ # failed 1 among 3 test(s)

+ 1..3

+ # faked up failures as TODO & now exiting with 0 due to --invert-exit-code

+ EOF

+'

+

+test_expect_success 'subtest: --invert-exit-code with --immediate: partial pass' '

+ run_sub_test_lib_test partial-pass \

+ --invert-exit-code --immediate &&

+ check_sub_test_lib_test partial-pass \

+ <<-\EOF_OUT 3<<-EOF_ERR

+ ok 1 - passing test #1

+ not ok 2 - # TODO induced breakage (--invert-exit-code): failing test #2

+ # false

+ 1..2

+ # faked up failures as TODO & now exiting with 0 due to --invert-exit-code

+ EOF_OUT

+ EOF_ERR

+'

+

+test_expect_success 'subtest: --invert-exit-code --immediate: got a failure' '

+ run_sub_test_lib_test partial-pass \

+ --invert-exit-code --immediate &&

+ check_sub_test_lib_test_err partial-pass \

+ <<-\EOF_OUT 3<<-EOF_ERR

+ ok 1 - passing test #1

+ not ok 2 - # TODO induced breakage (--invert-exit-code): failing test #2

+ # false

+ 1..2

+ # faked up failures as TODO & now exiting with 0 due to --invert-exit-code

+ EOF_OUT

+ EOF_ERR

+'

+

+test_expect_success 'check rev-list' '

+test_expect_success POSIXPERM,SANITY 'commit should notice unwritable repository' '

+ test_expect_code 129 git help --user-interfaces add &&

+

+

+test_expect_success 'git help --user-interfaces' '

+ git help --user-interfaces >help.output &&

+ grep "^ attributes " help.output &&

+ grep "^ mailmap " help.output

+'

+

+

+ User-facing repository, command and file interfaces

+

+ Developer-facing file file formats, protocols and interfaces

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+

+TEST_PASSES_SANITIZE_LEAK=true

+. "$TEST_DIRECTORY"/lib-perl.sh

+skip_all_if_no_Test_More

+test_expect_success 'run t0202/test.pl to test Git::I18N.pm' '

+ "$PERL_PATH" "$TEST_DIRECTORY"/t0202/test.pl 2>stderr &&

+ test_must_be_empty stderr

+'

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success 'checkout with modified sparse directory' '

+ init_repos &&

+

+ test_all_match git checkout rename-in-to-out -- . &&

+ test_sparse_match git sparse-checkout reapply &&

+ test_all_match git checkout base

+'

+

+test_expect_success 'reset hard with removed sparse dir' '

+ init_repos &&

+

+ run_on_all git rm -r --sparse folder1 &&

+ test_all_match git status --porcelain=v2 &&

+

+ test_all_match git reset --hard &&

+ test_all_match git status --porcelain=v2 &&

+

+ cat >expect <<-\EOF &&

+ folder1/

+ EOF

+

+ git -C sparse-index ls-files --sparse folder1 >out &&

+ test_cmp expect out

+'

+

+ run_on_all git rm -rf --sparse folder1/ &&

+ git -C sparse-index "$@" \

+ >sparse-index-out \

+ 2>sparse-index-error || return 1

+ git -C sparse-index "$@" \

+ >sparse-index-out \

+ 2>sparse-index-error || return 1

+test_expect_success 'rm pathspec inside sparse definition' '

+ init_repos &&

+

+ test_all_match git rm deep/a &&

+ test_all_match git status --porcelain=v2 &&

+

+ # test wildcard

+ run_on_all git reset --hard &&

+ test_all_match git rm deep/* &&

+ test_all_match git status --porcelain=v2 &&

+

+ # test recursive rm

+ run_on_all git reset --hard &&

+ test_all_match git rm -r deep &&

+ test_all_match git status --porcelain=v2

+'

+

+test_expect_success 'rm pathspec outside sparse definition' '

+ init_repos &&

+

+ for file in folder1/a folder1/0/1

+ do

+ test_sparse_match test_must_fail git rm $file &&

+ test_sparse_match test_must_fail git rm --cached $file &&

+ test_sparse_match git rm --sparse $file &&

+ test_sparse_match git status --porcelain=v2

+ done &&

+

+ cat >folder1-full <<-EOF &&

+ rm ${SQ}folder1/0/0/0${SQ}

+ rm ${SQ}folder1/0/1${SQ}

+ rm ${SQ}folder1/a${SQ}

+ EOF

+

+ cat >folder1-sparse <<-EOF &&

+ rm ${SQ}folder1/${SQ}

+ EOF

+

+ # test wildcard

+ run_on_sparse git reset --hard &&

+ run_on_sparse git sparse-checkout reapply &&

+ test_sparse_match test_must_fail git rm folder1/* &&

+ run_on_sparse git rm --sparse folder1/* &&

+ test_cmp folder1-full sparse-checkout-out &&

+ test_cmp folder1-sparse sparse-index-out &&

+ test_sparse_match git status --porcelain=v2 &&

+

+ # test recursive rm

+ run_on_sparse git reset --hard &&

+ run_on_sparse git sparse-checkout reapply &&

+ test_sparse_match test_must_fail git rm --sparse folder1 &&

+ run_on_sparse git rm --sparse -r folder1 &&

+ test_cmp folder1-full sparse-checkout-out &&

+ test_cmp folder1-sparse sparse-index-out &&

+ test_sparse_match git status --porcelain=v2

+'

+

+test_expect_success 'rm pathspec expands index when necessary' '

+ init_repos &&

+

+ # in-cone pathspec (do not expand)

+ ensure_not_expanded rm "deep/deep*" &&

+ test_must_be_empty sparse-index-err &&

+

+ # out-of-cone pathspec (expand)

+ ! ensure_not_expanded rm --sparse "folder1/a*" &&

+ test_must_be_empty sparse-index-err &&

+

+ # pathspec that should expand index

+ ! ensure_not_expanded rm "*/a" &&

+ test_must_be_empty sparse-index-err &&

+

+ ! ensure_not_expanded rm "**a" &&

+ test_must_be_empty sparse-index-err

+'

+

+test_expect_success 'sparse index is not expanded: rm' '

+ init_repos &&

+

+ ensure_not_expanded rm deep/a &&

+

+ # test in-cone wildcard

+ git -C sparse-index reset --hard &&

+ ensure_not_expanded rm deep/* &&

+

+ # test recursive rm

+ git -C sparse-index reset --hard &&

+ ensure_not_expanded rm -r deep

+'

+

+test_expect_success 'symbolic-ref refuses invalid target for non-HEAD' '

+ test_must_fail git symbolic-ref refs/heads/invalid foo..bar

+'

+

+test_expect_success 'symbolic-ref allows top-level target for non-HEAD' '

+ git symbolic-ref refs/heads/top-level FETCH_HEAD &&

+ git update-ref FETCH_HEAD HEAD &&

+ test_cmp_rev top-level HEAD

+'

+

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success 'tree entry with bogus mode' '

+ test_when_finished "remove_object \$blob" &&

+ test_when_finished "remove_object \$tree" &&

+ blob=$(echo blob | git hash-object -w --stdin) &&

+ blob_oct=$(echo $blob | hex2oct) &&

+ tree=$(printf "100000 foo\0${blob_oct}" |

+ git hash-object -t tree --stdin -w --literally) &&

+ git fsck 2>err &&

+ cat >expect <<-EOF &&

+ warning in tree $tree: badFilemode: contains bad file modes

+ EOF

+ test_cmp expect err

+'

+

+test_expect_success 'main@{n} for various n' '

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success 'git hook run a hook with a bad shebang' '

+ test_when_finished "rm -rf bad-hooks" &&

+ mkdir bad-hooks &&

+ write_script bad-hooks/test-hook "/bad/path/no/spaces" </dev/null &&

+

+ # TODO: We should emit the same (or at least a more similar)

+ # error on Windows and !Windows. See the OS-specific code in

+ # start_command()

+ if test_have_prereq !WINDOWS

+ then

+ cat >expect <<-\EOF

+ fatal: cannot run bad-hooks/test-hook: ...

+ EOF

+ else

+ cat >expect <<-\EOF

+ error: cannot spawn bad-hooks/test-hook: ...

+ EOF

+ fi &&

+ test_expect_code 1 git \

+ -c core.hooksPath=bad-hooks \

+ hook run test-hook >out 2>err &&

+ test_must_be_empty out &&

+ sed -e "s/test-hook: .*/test-hook: .../" <err >actual &&

+ test_cmp expect actual

+'

+

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success 'restore gitignore' '

+test_expect_success 'git status honors core.excludesfile' \

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success 'many notes created correctly with git-notes' '

+TEST_PASSES_SANITIZE_LEAK=true

+

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success 'GIT_EXTERNAL_DIFF environment should apply only to diff' '

+test_expect_success 'diff.external should apply only to diff' '

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success REFFILES 'log diagnoses bogus HEAD symref' '

+ echo "ref: refs/heads/invalid.lock" > empty/.git/HEAD &&

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+test_expect_success 'badFilemode is not a strict error' '

+ git init --bare badmode.git &&

+ tree=$(

+ cd badmode.git &&

+ blob=$(echo blob | git hash-object -w --stdin | hex2oct) &&

+ printf "123456 foo\0${blob}" |

+ git hash-object -t tree --stdin -w --literally

+ ) &&

+

+ rm -rf dst.git &&

+ git init --bare dst.git &&

+ git -C dst.git config transfer.fsckObjects true &&

+

+ git -C badmode.git push ../dst.git $tree:refs/tags/tree 2>err &&

+ grep "$tree: badFilemode" err

+'

+

+ # as an Extra Parameter (see "git help gitformat-pack-protocol"), so that

+ # "info/refs" can serve refs, just like it does in protocol v0.

+test_expect_success 'TODO (should fail!): traverse unexpected non-blob entry (lone)' '

+test_expect_success 'TODO (should fail!): traverse unexpected non-blob tag (lone)' '

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+TEST_PASSES_SANITIZE_LEAK=true

+. ./test-lib.sh

+. "$TEST_DIRECTORY"/lib-perl.sh

+skip_all_if_no_Test_More

+test_expect_success 'use t9700/test.pl to test Git.pm' '

+ "$PERL_PATH" "$TEST_DIRECTORY"/t9700/test.pl 2>stderr &&

+ test_must_be_empty stderr

+'

+TEST_PASSES_SANITIZE_LEAK=true

+# test_expect_{success,failure}

+ --invert-exit-code)

+ invert_exit_code=t

+ ;;

+TEST_RESULTS_SAN_FILE_PFX=trace

+TEST_RESULTS_SAN_DIR_SFX=leak

+TEST_RESULTS_SAN_FILE=

+TEST_RESULTS_SAN_DIR="$TEST_RESULTS_DIR/$TEST_NAME.$TEST_RESULTS_SAN_DIR_SFX"

+TEST_RESULTS_SAN_DIR_NR_LEAKS_STARTUP=

+# Utility functions using $TEST_RESULTS_* variables

+nr_san_dir_leaks_ () {

+ # stderr piped to /dev/null because the directory may have

+ # been "rmdir"'d already.

+ find "$TEST_RESULTS_SAN_DIR" \

+ -type f \

+ -name "$TEST_RESULTS_SAN_FILE_PFX.*" 2>/dev/null |

+ wc -l

+}

+

+ _USE_GLIBC_TUNABLES=

+ if _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&

+ _GLIBC_VERSION=${_GLIBC_VERSION#"glibc "} &&

+ expr 2.34 \<= "$_GLIBC_VERSION" >/dev/null

+ then

+ _USE_GLIBC_TUNABLES=YesPlease

+ fi

+ if test -n "$_USE_GLIBC_TUNABLES"

+_invert_exit_code_failure_end_blurb () {

+ say_color warn "# faked up failures as TODO & now exiting with 0 due to --invert-exit-code"

+}

+

+ local pfx=""

+ if test -n "$invert_exit_code" # && test -n "$HARNESS_ACTIVE"

+ then

+ pfx="# TODO induced breakage (--invert-exit-code):"

+ fi

+ say_color error "not ok $test_count - ${pfx:+$pfx }$1"

+ if test -n "$invert_exit_code"

+ then

+ finalize_test_output

+ _invert_exit_code_failure_end_blurb

+ GIT_EXIT_OK=t

+ exit 0

+ fi

+ say_color error "ok $test_count - $1 # TODO known breakage vanished"

+ finalize_test_case_output fixed "$1"

+ say_color warn "not ok $test_count - $1 # TODO known breakage"

+ finalize_test_case_output broken "$1"

+sanitize_leak_log_message_ () {

+ local new="$1" &&

+ local old="$2" &&

+ local file="$3" &&

+

+ printf "With SANITIZE=leak at exit we have %d leak logs, but started with %d

+

+This means that we have a blindspot where git is leaking but we're

+losing the exit code somewhere, or not propagating it appropriately

+upwards!

+

+See the logs at \"%s.*\";

+those logs are reproduced below." \

+ "$new" "$old" "$file"

+}

+

+check_test_results_san_file_ () {

+ if test -z "$TEST_RESULTS_SAN_FILE"

+ then

+ return

+ fi &&

+ local old="$TEST_RESULTS_SAN_DIR_NR_LEAKS_STARTUP" &&

+ local new="$(nr_san_dir_leaks_)" &&

+

+ if test $new -le $old

+ then

+ return

+ fi &&

+ local out="$(sanitize_leak_log_message_ "$new" "$old" "$TEST_RESULTS_SAN_FILE")" &&

+ say_color error "$out" &&

+ if test "$old" != 0

+ then

+ echo &&

+ say_color error "The logs include output from past runs to avoid" &&

+ say_color error "that remove 'test-results' between runs."

+ fi &&

+ say_color error "$(cat "$TEST_RESULTS_SAN_FILE".*)" &&

+ if test -n "$passes_sanitize_leak" && test "$test_failure" = 0

+ then

+ say "As TEST_PASSES_SANITIZE_LEAK=true and our logs show we're leaking, exit non-zero!" &&

+ invert_exit_code=t

+ elif test -n "$passes_sanitize_leak"

+ then

+ say "As TEST_PASSES_SANITIZE_LEAK=true and our logs show we're leaking, and we're failing for other reasons too..." &&

+ invert_exit_code=

+ elif test -n "$sanitize_leak_check" && test "$test_failure" = 0

+ then

+ say "As TEST_PASSES_SANITIZE_LEAK=true isn't set the above leak is 'ok' with GIT_TEST_PASSING_SANITIZE_LEAK=check" &&

+ invert_exit_code=

+ elif test -n "$sanitize_leak_check"

+ then

+ say "As TEST_PASSES_SANITIZE_LEAK=true isn't set the above leak is 'ok' with GIT_TEST_PASSING_SANITIZE_LEAK=check" &&

+ invert_exit_code=t

+ else

+ say "With GIT_TEST_SANITIZE_LEAK_LOG=true our logs revealed a memory leak, exit non-zero!" &&

+ invert_exit_code=t

+ fi

+}

+

+test_done () {

+ if test $test_remaining -gt 0

+ say_color pass "# passed all $msg"

+ # Maybe print SKIP message

+ test -z "$skip_all" || skip_all="# SKIP $skip_all"

+ case "$test_count" in

+ 0)

+ say "1..$test_count${skip_all:+ $skip_all}"

+ ;;

+ *)

+ test -z "$skip_all" ||

+ say_color warn "$skip_all"

+ say "1..$test_count"

+ ;;

+ esac

+

+ if test -n "$stress" && test -n "$invert_exit_code"

+ then

+ # We're about to move our "$TRASH_DIRECTORY"

+ # to "$TRASH_DIRECTORY.stress-failed" if

+ # --stress is combined with

+ # --invert-exit-code.

+ say "with --stress and --invert-exit-code we're not removing '$TRASH_DIRECTORY'"

+ elif test -z "$debug" && test -n "$remove_trash"

+

+ check_test_results_san_file_ "$test_failure"

+

+ if test -z "$skip_all" && test -n "$invert_exit_code"

+ then

+ say_color warn "# faking up non-zero exit with --invert-exit-code"

+ GIT_EXIT_OK=t

+ exit 1

+ fi

+

+ GIT_EXIT_OK=t

+ say_color error "# failed $test_failure among $msg"

+ say "1..$test_count"

+

+ check_test_results_san_file_ "$test_failure"

+

+ if test -n "$invert_exit_code"

+ _invert_exit_code_failure_end_blurb

+ GIT_EXIT_OK=t

+ exit 0

+ GIT_EXIT_OK=t

+ BAIL_OUT "You haven't built things yet, have you?"

+ BAIL_OUT 'You need to build test-tool; Run "make t/helper/test-tool" in the source (toplevel) directory'

+BAIL_OUT_ENV_NEEDS_SANITIZE_LEAK () {

+ BAIL_OUT "$1 has no effect except when compiled with SANITIZE=leak"

+}

+

+ # Normalize with test_bool_env

+ passes_sanitize_leak=

+

+ # We need to see TEST_PASSES_SANITIZE_LEAK in "git

+ # env--helper" (via test_bool_env)

+ export TEST_PASSES_SANITIZE_LEAK

+ if test_bool_env TEST_PASSES_SANITIZE_LEAK false

+ then

+ passes_sanitize_leak=t

+ fi

+

+ if test "$GIT_TEST_PASSING_SANITIZE_LEAK" = "check"

+ sanitize_leak_check=t

+ if test -n "$invert_exit_code"

+ then

+ BAIL_OUT "cannot use --invert-exit-code under GIT_TEST_PASSING_SANITIZE_LEAK=check"

+ fi

+ if test -z "$passes_sanitize_leak"

+ say "in GIT_TEST_PASSING_SANITIZE_LEAK=check mode, setting --invert-exit-code for TEST_PASSES_SANITIZE_LEAK != true"

+ invert_exit_code=t

+ elif test -z "$passes_sanitize_leak" &&

+ test_bool_env GIT_TEST_PASSING_SANITIZE_LEAK false

+ then

+ skip_all="skipping $this_test under GIT_TEST_PASSING_SANITIZE_LEAK=true"

+ test_done

+

+ if test_bool_env GIT_TEST_SANITIZE_LEAK_LOG false

+ then

+ if ! mkdir -p "$TEST_RESULTS_SAN_DIR"

+ then

+ BAIL_OUT "cannot create $TEST_RESULTS_SAN_DIR"

+ fi &&

+ TEST_RESULTS_SAN_FILE="$TEST_RESULTS_SAN_DIR/$TEST_RESULTS_SAN_FILE_PFX"

+

+ # In case "test-results" is left over from a previous

+ # run: Only report if new leaks show up.

+ TEST_RESULTS_SAN_DIR_NR_LEAKS_STARTUP=$(nr_san_dir_leaks_)

+

+ # Don't litter *.leak dirs if there was nothing to report

+ test_atexit "rmdir \"$TEST_RESULTS_SAN_DIR\" 2>/dev/null || :"

+

+ prepend_var LSAN_OPTIONS : dedup_token_length=9999

+ prepend_var LSAN_OPTIONS : log_exe_name=1

+ prepend_var LSAN_OPTIONS : log_path=\"$TEST_RESULTS_SAN_FILE\"

+ export LSAN_OPTIONS

+ fi

+elif test "$GIT_TEST_PASSING_SANITIZE_LEAK" = "check" ||

+ test_bool_env GIT_TEST_PASSING_SANITIZE_LEAK false

+then

+ BAIL_OUT_ENV_NEEDS_SANITIZE_LEAK "GIT_TEST_PASSING_SANITIZE_LEAK=true"

+elif test_bool_env GIT_TEST_SANITIZE_LEAK_LOG false

+ BAIL_OUT_ENV_NEEDS_SANITIZE_LEAK "GIT_TEST_SANITIZE_LEAK_LOG=true"

+ BAIL_OUT 'cannot prepare test area'

+cd -P "$TRASH_DIRECTORY" || BAIL_OUT "cannot cd -P to \"$TRASH_DIRECTORY\""

+ desc->entry.mode = (desc->flags & TREE_DESC_RAW_MODES) ? mode : canon_mode(mode);

+static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer,

+ unsigned long size, struct strbuf *err,

+ enum tree_desc_flags flags)

+ desc->flags = flags;

+ if (init_tree_desc_internal(desc, buffer, size, &err, 0))

+int init_tree_desc_gently(struct tree_desc *desc, const void *buffer, unsigned long size,

+ enum tree_desc_flags flags)

+ int result = init_tree_desc_internal(desc, buffer, size, &err, flags);

+

+ /* option flags passed via init_tree_desc_gently() */

+ enum tree_desc_flags {

+ TREE_DESC_RAW_MODES = (1 << 0),

+ } flags;

+int init_tree_desc_gently(struct tree_desc *desc, const void *buf, unsigned long size,

+ enum tree_desc_flags flags);

+ * Determine whether the path specified by 'p' should be unpacked as a new

+ * sparse directory in a sparse index. A new sparse directory 'A/':

+ * - must be outside the sparse cone.

+ * - must not already be in the index (i.e., no index entry with name 'A/'

+ * exists).

+ * - must not have any child entries in the index (i.e., no index entry

+ * 'A/<something>' exists).

+ * If 'p' meets the above requirements, return 1; otherwise, return 0.

+ */

+static int entry_is_new_sparse_dir(const struct traverse_info *info,

+ const struct name_entry *p)

+{

+ int res, pos;

+ struct strbuf dirpath = STRBUF_INIT;

+ struct unpack_trees_options *o = info->data;

+

+ if (!S_ISDIR(p->mode))

+ return 0;

+

+ /*

+ * If the path is inside the sparse cone, it can't be a sparse directory.

+ */

+ strbuf_add(&dirpath, info->traverse_path, info->pathlen);

+ strbuf_add(&dirpath, p->path, p->pathlen);

+ strbuf_addch(&dirpath, '/');

+ if (path_in_cone_mode_sparse_checkout(dirpath.buf, o->src_index)) {

+ res = 0;

+ goto cleanup;

+ }

+

+ pos = index_name_pos_sparse(o->src_index, dirpath.buf, dirpath.len);

+ if (pos >= 0) {

+ /* Path is already in the index, not a new sparse dir */

+ res = 0;

+ goto cleanup;

+ }

+

+ /* Where would this sparse dir be inserted into the index? */

+ pos = -pos - 1;

+ if (pos >= o->src_index->cache_nr) {

+ /*

+ * Sparse dir would be inserted at the end of the index, so we

+ * know it has no child entries.

+ */

+ res = 1;

+ goto cleanup;

+ }

+

+ /*

+ * If the dir has child entries in the index, the first would be at the

+ * position the sparse directory would be inserted. If the entry at this

+ * position is inside the dir, not a new sparse dir.

+ */

+ res = strncmp(o->src_index->cache[pos]->name, dirpath.buf, dirpath.len);

+

+cleanup:

+ strbuf_release(&dirpath);

+ return res;

+}

+

+/*

+ const struct traverse_info *info,

+ int *is_new_sparse_dir)

+ const struct name_entry *p = names;

+ *is_new_sparse_dir = 0;

+ if (mask == dirmask && !src[0]) {

+ /*

+ * If we're not in a sparse index, we can't unpack a directory

+ * without recursing into it, so we return.

+ */

+ if (!o->src_index->sparse_index)

+ return 0;

+

+ /* Find first entry with a real name (we could use "mask" too) */

+ while (!p->mode)

+ p++;

+

+ /*

+ * If the directory is completely missing from the index but

+ * would otherwise be a sparse directory, we should unpack it.

+ * If not, we'll return and continue recursively traversing the

+ * tree.

+ */

+ *is_new_sparse_dir = entry_is_new_sparse_dir(info, p);

+ if (!*is_new_sparse_dir)

+ return 0;

+ }

+ * When we are unpacking a sparse directory, then this isn't necessarily

+ * a directory-file conflict.

+ if (mask == dirmask &&

+ (*is_new_sparse_dir || (src[0] && S_ISSPARSEDIR(src[0]->ce_mode))))

+ int ret, is_new_sparse_dir;

+ ret = unpack_single_entry(n - 1, mask >> 1, dirmask >> 1, src, names + 1, info, &is_new_sparse_dir);

+ int is_new_sparse_dir;

+ if (unpack_single_entry(n, mask, dirmask, src, names, info, &is_new_sparse_dir))

+ !is_new_sparse_dir &&

+ free(output_state);