DOCSEARCHbyAlgolia
Submit Docs

Git Documentation

repository·gh-pages·Indexed 40 days ago

https://github.com/git/htmldocs

Official documentation for Git, a distributed version control system. Includes manuals, guides, and detailed information on patch generation, the git-apply command, and upcoming breaking changes in Git 3.0, such as the transition to SHA-256 as the default hash function, reftable reference storage, and mandatory Rust build requirements.

Tokens
106.9K
Snippets
561
Records
850
Agent score
47%

What's inside Git

  1. Overview of git-fast-import

    gh-pages

    git fast-import is a backend program designed for high-performance Git data ingestion. It reads a mixed command/data stream from standard input and writes packfiles directly into a Git repository.

    Key Characteristics:

    • Usage: It is typically not run directly by end-users but is used as a backend by "frontend" programs that parse foreign source data (e.g., CVS, SVN) and feed it to fast-import.
    • Capabilities: It can import into an empty repository (initialized via git init) or incrementally update an existing repository.
    • Performance: Designed to handle massive projects (100,000+ commits) efficiently by minimizing memory usage and disk I/O contention.
    • Safety: It does not use or alter the current working directory, making it safe to run alongside other Git operations like git gc or git repack.

  2. Optimize Git repository data with git-maintenance

    gh-pages
    The git maintenance command automates tasks to optimize Git repository data. This improves the performance of other Git commands and reduces storage requirements. It is designed to run background tasks so that heavy operations (like garbage collection) do not interrupt the user experience during active commands like git add or git fetch.

  3. Get object contents or details with git-cat-file

    gh-pages

    The git cat-file command is used to output the contents or properties (such as size, type, or delta information) of repository objects.

    It operates in two modes:

    1. Non-batch mode: Provides information for a specific object named on the command line.
    2. Batch mode: Reads arguments from standard input (triggered by --batch, --batch-check, or --batch-command).
    git cat-file <type> <object>
git cat-file -t <object>
git cat-file -s <object>

  4. Upcoming breaking changes in Git 3.0

    gh-pages
    Git 3.0 is a planned major release that will introduce several breaking changes to improve security, performance, and maintainability. These changes include shifts in default hash functions, reference storage formats, default branch names, and build requirements. Users should prepare for these changes by monitoring deprecation warnings and adopting recommended alternatives.

  5. Manage tracked repositories with git-remote

    gh-pages

    The git remote command is used to manage the set of repositories (called "remotes") whose branches you track. Running git remote without arguments lists all existing remotes. Use the -v or --verbose flag to see the remote URLs alongside their names.

    # List remotes
git remote

# List remotes with URLs
git remote -v

  6. What is an Object Walk vs. a Revision Walk?

    gh-pages

    In Git, these two concepts represent different ways of traversing the object database:

    • Object Walk: The process of traversing all object types (commits, trees, blobs, and tags) by following containment and parent relationships. This is used for operations like fsck or object transfers.
    • Revision Walk: A specialized walk focused exclusively on commit objects and their parent relationships. It does not delve into trees or blobs. This is the mechanism used by git log.

  7. What is Partial Clone and when to use it

    gh-pages

    Partial Clone is a performance optimization for Git designed to handle extremely large repositories. Instead of downloading the complete history (all commits, trees, and blobs), Git downloads only a subset of objects. This reduces initial clone/fetch times and disk usage.

    Common use cases include:

    1. Narrowing the tree: Avoiding downloading files outside of a specific directory structure (e.g., using a 'cone' filter).
    2. Avoiding large binaries: Avoiding downloading previous versions of large, non-mergeable binary assets, only fetching them when actually referenced.

    Note: Partial clone is independent of DAG-level mechanisms like shallow clones or single-branch fetches. It specifically limits the number of blobs and trees within a given range of commits.

  8. What is Scalar and how does it work?

    gh-pages

    Scalar is a repository management tool designed to optimize Git for large-scale repositories. It achieves this by automatically configuring advanced Git performance features that are often too experimental or specialized for general use.

    Unlike standard Git commands, Scalar is a standalone executable rather than a Git subcommand. It interacts with Git by invoking Git child processes and using libgit.a directly.

    Scalar provides two primary functions:

    1. Automatic Configuration: It enables and manages high-performance Git features like partial clone, commit graphs, multi-pack index, and sparse checkout (cone mode).
    2. Enlistment Management: It tracks which repositories on a system should use Scalar-configured features, allowing for centralized maintenance and updates to performance settings.

  9. Manage shared repositories with hooks

    gh-pages

    Git hooks allow you to run scripts at specific points in the development lifecycle. For shared repositories, you can use:

    • General hooks: To automate tasks like sending all commits to a mailing list.
    • Update hooks: To enforce fine-grained permissions and control access to specific branches.

  11. Understand Git CLI argument conventions

    gh-pages

    Git commands follow a specific order for arguments to avoid ambiguity:

    1. Options first, then arguments: Always provide dashed options (e.g., --max-parents 2) before non-option arguments.
    2. Revisions before paths: When a command accepts both, provide the revision (commit, tree-ish) before the file path.
    3. Disambiguating with --: If an argument could be interpreted as either a revision or a path, use -- to separate them.
      • git diff -- HEAD: Treats HEAD as a path (a file named HEAD in the work tree).
      • git diff HEAD --: Treats HEAD as a revision (the HEAD commit).

    Note on Wildcards: To prevent your shell from expanding fileglobs and instead let Git handle the pattern matching, escape the wildcard with a backslash.

    • git restore *.c: Shell expands *.c to files currently in your working tree.
    • git restore \*.c: Git receives *.c and matches paths in the index.
    # Example of revision vs path disambiguation
git diff -- HEAD
git diff HEAD --

# Example of protecting wildcards from shell expansion
git restore \*.c

  12. Follow symlinks in batch mode

    gh-pages

    When using --batch or --batch-check, the --follow-symlinks flag allows you to resolve symlinks within the repository when using extended SHA-1 expressions (e.g., tree-ish:path-in-tree).

    • Without this flag, cat-file returns data about the symlink itself.
    • With this flag, it returns data about the object the symlink points to.
    • If a symlink points outside the tree-ish, the portion outside the tree is printed.

    Note: This does not currently work correctly when specifying an object in the index (e.g., :link).

    echo "HEAD:link" | git cat-file --batch --follow-symlinks