# CommandSection

title: CAVEATS
content:
For very large diffs, <i>git-delta</i> might introduce a slight performance overhead compared to plain `less`, although it is generally well-optimized. Optimal functionality and appearance often require a true-color compatible terminal emulator. Users typically need to configure `git` to use `delta` as its default pager, which involves modifying the `.gitconfig` file.


title: CONFIGURATION
content:
<i>git-delta</i> is extensively configurable via Git's configuration system. Users commonly set `core.pager=delta` in their global or repository-specific `.gitconfig` file, or define Git aliases (e.g., `git config --global alias.d 'diff --color | delta'`) to invoke `delta` with specific options. This allows for deep personalization of diff display based on user preferences and project requirements.


title: HISTORY
content:
<i>git-delta</i> was created by `dandavison` and first released in 2019. Developed in Rust, its primary motivation was to provide a highly customizable and aesthetically pleasing alternative to existing diff pagers, addressing limitations in readability and visual presentation. It quickly gained adoption within the Git community due to its advanced features like intelligent syntax highlighting and superior layout options.


title: SYNOPSIS
content:
<b>git diff</b> [<I>options</I>] [<I>tree-ish</I> [<I>tree-ish</I>]] [--] [<I>path</I>...]<br><b>git diff</b> [<I>options</I>] <b>--cached</b> [<I>tree-ish</I>] [--] [<I>path</I>...]<br><b>git diff</b> [<I>options</I>] <b>--staged</b> [<I>tree-ish</I>] [--] [<I>path</I>...]<br><b>git diff</b> [<I>options</I>] <b>--no-index</b> [--] <I>path</I> <I>path</I>


title: PARAMETERS
content:
<b>--patch or -p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a patch (diff output). This is the default behaviour.<br><br><b>--stat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a diffstat, showing a summary of changes (files changed, lines added/deleted).<br><br><b>--name-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the names of affected files.<br><br><b>--name-status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show names and status (A, C, D, M, R, T, U, X, B) of affected files.<br><br><b>--check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Warn if the changes introduce whitespace errors.<br><br><b>--color / --no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turn on or off colored diff output.<br><br><b>--word-diff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show word-by-word differences instead of line-by-line.<br><br><b>--unified=<n> or -U<n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate diffs with <I>n</I> lines of context around the changes.<br><br><b>--binary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output a binary diff that can be applied with <b>git apply</b>.<br><br><b>--cached or --staged</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare the index (staging area) with the specified <I>tree-ish</I> (defaulting to HEAD).<br><br><b>--no-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare two arbitrary files or directories outside of a Git repository.<br><br><b><path>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the diff to changes within the specified file(s) or directory/directories.<br><br><b><tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A commit hash, branch name, tag name, or other Git object reference to compare against.<br><br>


title: DESCRIPTION
content:
The <b>git-diff</b> command is a fundamental Git utility used to display differences between various parts of your Git repository. It can compare the working directory with the staging area (index), the working directory with the last committed state (HEAD), the staging area with HEAD, or even differences between any two commits, branches, or tags.<br><br>It's an indispensable tool for reviewing changes before committing, understanding modifications made by others, debugging inconsistencies, or simply exploring the evolution of a codebase. By default, <b>git-diff</b> shows line-by-line textual differences (hunks) in a unified format, highlighting additions and deletions. It supports numerous options to customize the output, allowing users to view concise summaries, file names only, or detailed word-by-word comparisons.


title: CAVEATS
content:
<b>git-diff</b> typically doesn't show line-by-line differences for binary files; it merely indicates that they differ. Detailed binary diffs often require external tools or Git attribute configurations. For very large files or extensive changes across many files, the output can be substantial and resource-intensive. It also primarily focuses on tracked files; untracked files are ignored unless specifically referenced with <b>--no-index</b>.


title: COMMON COMPARISON SCENARIOS
content:
<b>git-diff</b> is highly versatile. By default, with no arguments, it compares your working directory with the staging area (index). Adding a single <I>tree-ish</I> (e.g., <b>git diff HEAD</b>) compares the working directory with the last commit. Using <b>--cached</b> (or <b>--staged</b>) compares the staging area with the last commit. Comparing two arbitrary commits is done with <b>git diff <I>commit1</I> <I>commit2</I></b>. The <b><I>commit1</I>...<I>commit2</I></b> syntax shows changes on <I>commit2</I> since the common ancestor with <I>commit1</I>.


title: OUTPUT TYPES
content:
Beyond the default patch output, <b>git-diff</b> offers specialized views. <b>--stat</b> provides a concise summary of affected files and line changes. <b>--name-only</b> lists only the filenames. <b>--name-status</b> adds the file status (e.g., modified, added, deleted). For detailed word-level changes, <b>--word-diff</b> is invaluable, especially for text documents.


title: HISTORY
content:
As a core command, <b>git-diff</b> has been an integral part of Git since its inception in 2005. It leverages the underlying diffing algorithms but applies them to Git's object model (blobs and trees). Its functionality has steadily evolved, adding more powerful options for output formatting, context control, and diverse comparison scenarios, adapting to the growing needs of version control users.


title: SYNOPSIS
content:
<i>git diff-files</i> [--raw] [--name-only | --name-status] [-z] [--diff-filter=<I>filter</I>] [-- <I>path</I>...]


title: PARAMETERS
content:
<b>--raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the raw diff output. This format is designed for easy parsing by scripts.<br><br><b>--name-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the names of the files that differ, one per line.<br><br><b>--name-status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the names and status letters of the files that differ (e.g., A for added, M for modified, D for deleted).<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Separate the pathnames with a NUL character instead of a newline. This is useful for scripting when dealing with pathnames that may contain spaces or other special characters.<br><br><b>--diff-filter=<I>filter</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type changed (T), are Unmerged (U), are Unknown (X), or have Broken pairing (B). Any combination of these characters can be used.<br><br><b>-- <I>path</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the diff to the specified paths. This separator (--) is optional but recommended to distinguish paths from options.<br><br>


title: DESCRIPTION
content:
The <b>git-diff-files</b> command, typically invoked via <i>git diff-files</i>, serves as a low-level <I>plumbing</I> command in Git. Its primary function is to compare the contents and metadata of files in your current working directory against their versions stored in the Git index (also known as the staging area).<br><br>Unlike the more common <i>git diff</i> which offers various comparison modes (e.g., between commits, branches), <b>git-diff-files</b> focuses solely on the unstaged changes. It is designed for scripting and internal Git operations, providing raw, precise information about what has changed in the working tree relative to what is prepared for the next commit.<br><br>It can report added, modified, deleted, renamed, copied, or type-changed files, making it a foundational tool for building more complex Git workflows and utilities.


title: CAVEATS
content:
<b>git-diff-files</b> is primarily a <I>plumbing</I> command. For general interactive use, <i>git diff</i> (specifically <i>git diff --no-index</i> or <i>git diff</i> without arguments) is usually more appropriate and user-friendly. This command only compares the working directory against the index; it cannot compare against commits or other references.


title: USAGE PATTERN
content:
While the executable is named <i>git-diff-files</i>, it is almost always invoked indirectly through the main <i>git</i> command as <i>git diff-files</i>. Direct execution of <i>git-diff-files</i> is rare and typically not required for standard Git operations.


title: HISTORY
content:
<b>git-diff-files</b> is one of the foundational low-level commands introduced early in Git's development. It provides the core mechanism for comparing changes between the working tree and the index, which is fundamental to Git's staging area concept and how it tracks uncommitted changes. Its design as a 'plumbing' command reflects Git's philosophy of providing basic, composable tools.


title: PARAMETERS
content:
<b>--cached, --staged</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare the specified tree object with the Git index.<br><br><b>--raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate output in a raw format, showing only the differences essential for scripting.<br><br><b>--name-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the names of changed files, one per line.<br><br><b>--name-status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the names of changed files along with their status (e.g., A for added, M for modified, D for deleted).<br><br><b>--diff-filter=[(A|C|D|M|R|T|U|X|B)...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B).<br><br><b>-M[<n>], --find-renames[=<n>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detect renames. An optional similarity threshold <I><n></I> (default 50%) can be specified.<br><br><b>-C[<n>], --find-copies[=<n>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detect copies. An optional similarity threshold <I><n></I> (default 50%) can be specified.<br><br><b>--no-renames</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turn off rename detection, even if configured globally.<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Separate output entries with a NUL character instead of a newline, useful for scripting with file names containing unusual characters.<br><br><b><tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of a tree object, typically a commit ID, branch name, or tag name, to compare against.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A standard convention used to separate command options from positional arguments (like paths).<br><br><b>[<path>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional paths to limit the comparison to specific files or directories.<br><br>


title: DESCRIPTION
content:
The <I>git-diff-index</I> command is a low-level <I>(plumbing)</I> command used to compare a <I>tree-ish</I> object (like a commit, branch, or tag) against the Git index or the files in the working directory.<br><br>When invoked with the <I>--cached</I> or <I>--staged</I> option, it compares the specified <I>tree-ish</I> with the content of the Git index. Without these options, it compares the <I>tree-ish</I> with the files in the working directory.<br><br>Its primary purpose is to provide raw, scriptable output about differences, often used by other Git commands (like <I>git diff</I>) to perform their higher-level comparisons. It can detect changes, additions, deletions, renames, and copies of files between the two points of comparison. Its output format is terse and designed for machine parsing rather than human readability.


title: CAVEATS
content:
This command is a low-level <I>plumbing</I> command. Its output format is designed for machine parsing and is not easily human-readable. It may behave unexpectedly or produce complex output for unmerged paths in the index.


title: RAW OUTPUT FORMAT
content:
When using the <I>--raw</I> option, <I>git-diff-index</I> produces output lines that typically start with a letter indicating the status (A, C, D, M, R, T, U, X, B), followed by old and new mode, old and new object names (hashes), and finally the old and new file names. This format is highly precise and intended for automated parsing by scripts.


title: HISTORY
content:
As a <I>plumbing</I> command, <I>git-diff-index</I> has been a fundamental part of Git since its early days. It provides the core functionality for comparing tree-like objects with the index or working tree, forming the basis for many higher-level <I>git diff</I> commands. Its stability and predictable output make it crucial for scripting and internal Git operations.


title: PARAMETERS
content:
<b>-r, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurse into subtrees when comparing files.<br><br><b>-m, --merges</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show diffs for all parents of a merge commit.<br><br><b>-c, --cc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show combined diff for merge commits. Implies <I>--merges</I>.<br><br><b>--stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read <I>tree-ish</I> arguments from standard input.<br><br><b>--stat[=<width>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a diffstat summary of file changes. Optional <I>width</I> for output column width.<br><br><b>--numstat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <I>--stat</I>, but shows number of added and deleted lines, and pathname.<br><br><b>--name-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only names of changed files.<br><br><b>--name-status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show names and status (A, C, D, M, R, T, U, X, B) of changed files.<br><br><b>--raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the raw Git diff output format, which includes modes and object IDs.<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use NUL character as file name separator, instead of newline. Useful for scripting.<br><br><b>--diff-filter=<A|C|D|M|R|T|U|X|B>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B).<br><br><b>--find-copies[=<n>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detect copied files, with optional similarity index <I>n</I> (0-100%).<br><br><b>--find-renames[=<n>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detect renamed files, with optional similarity index <I>n</I> (0-100%).<br><br><b>--find-rewrites[=<n>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detect rewritten files, with optional similarity index <I>n</I> (0-100%).<br><br><b>--no-renames</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turn off rename detection.<br><br><b>--submodule[=<format>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify how changes in submodules are shown. Format can be 'short' or 'log'.<br><br><b><tree-ish-1></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The object name of the first tree or commit to compare (e.g., a branch name, commit hash, or tag).<br><br><b><tree-ish-2></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The object name of the second tree or commit to compare. If omitted, and <I>tree-ish-1</I> is a commit, it compares <I>tree-ish-1</I> to its first parent.<br><br><b><path>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the diff to the specified paths (directories or files) within the trees.<br><br>


title: DESCRIPTION
content:
<b>git-diff-tree</b> is a <i>plumbing</i> command used to compare the content and mode of blobs or trees between two <I>tree-ish</I> objects. It outputs the differences as a raw diff or a diffstat, showing what changed between the specified trees. Unlike the more user-friendly <b>git diff</b> (a <I>porcelain</I> command), <b>git-diff-tree</b> is designed for scripting and low-level operations, providing precise control over the comparison process. It can show changes introduced by a commit by comparing the commit's tree with its parent's tree. The output format is highly customizable, allowing users to extract specific information about added, deleted, or modified files, along with their modes and object IDs. This command is fundamental for understanding how Git tracks changes at a detailed object level and is often used by other Git commands internally.


title: CAVEATS
content:
As a <i>plumbing</i> command, <b>git-diff-tree</b>'s output is optimized for machine parsing rather than human readability, making it less intuitive for direct use compared to <b>git diff</b>. It operates purely on Git's object model and does not directly compare with the working directory or index.


title: RAW OUTPUT FORMAT
content:
When using the <I>--raw</I> option, <b>git-diff-tree</b> outputs lines detailing the mode, object ID, and status (A, D, M, etc.) of files. This machine-readable format is essential for scripts that need to process file changes precisely and consistently.


title: COMPARING COMMITS
content:
A very common use case for <b>git-diff-tree</b> is to see the exact changes introduced by a specific commit. This is typically achieved by comparing the commit's tree with its first parent's tree, for example, <I>git diff-tree &lt;commit&gt;^ &lt;commit&gt;</I>.


title: HISTORY
content:
<b>git-diff-tree</b> has been a core component of Git since its inception, essential for understanding and calculating differences directly from Git's internal object model. Its stable, machine-readable output format has made it a foundational tool for building higher-level Git commands and custom scripts.


title: PARAMETERS
content:
<b>-t <tool>, --tool=<tool></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the graphical diff tool to use (e.g., <I>meld</I>, <I>kdiff3</I>, <I>vscode</I>). This option overrides the <I>diff.tool</I> configuration.<br><br><b>--tool-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a list of all available and configured diff tools that <b><I>git-difftool</I></b> recognizes.<br><br><b>--dir-diff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare files by directly showing two directories to the diff tool instead of opening individual files. The external tool must support directory comparison for this to work.<br><br><b>--no-prompt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt before launching each diff tool. The tool will be launched automatically for all changed files without user interaction.<br><br><b>--prompt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt before launching each diff tool. This is the default behavior when multiple files are involved, allowing users to skip or continue to the next file.<br><br><b>--extcmd=<command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an external command for comparison instead of a configured tool. The command receives seven arguments representing different versions of the file and its status.<br><br><b>--cached, --staged</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare the changes between the index (staged changes) and the <I>HEAD</I> commit. This is equivalent to <I>git difftool HEAD</I>.<br><br><b>--no-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare two arbitrary files on the filesystem. Requires exactly two file paths as arguments after this option.<br><br><b><commit></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify one or two commits to compare. If one commit is given, it compares the working tree with that commit. If two commits are given, it compares the content between the two commits.<br><br><b>[--] <path>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the diff to specific files or directories. The double dash (<I>--</I>) is used to separate options from path arguments, especially if paths might conflict with options.<br><br>


title: DESCRIPTION
content:
The <b><I>git-difftool</I></b> command allows users to visually inspect differences between Git revisions using a preferred external graphical diff viewer. Unlike <b><I>git diff</I></b>, which outputs changes directly to the terminal, <b><I>git-difftool</I></b> launches an application like Meld, KDiff3, Beyond Compare, or VS Code to display the file changes in a user-friendly graphical interface.<br><br>It can be used to compare the working tree with the index, a specific commit, or between two arbitrary commits. When multiple files have changes, <b><I>git-difftool</I></b> will open each modified file sequentially in the configured diff viewer, often prompting the user to continue to the next file or exit. This makes it invaluable for detailed code reviews, understanding complex changes, or resolving discrepancies visually.


title: CAVEATS
content:
<b><I>git-difftool</I></b> requires an external diff viewer application to be installed and correctly configured on your system. Without a properly configured tool, the command will either fail or prompt you to install and configure one. Configuration typically involves setting <I>diff.tool</I> and optionally <I>difftool.<tool>.path</I> in your Git configuration, as well as ensuring the tool's executable is in your system's PATH.


title: CONFIGURATION
content:
To use <b><I>git-difftool</I></b> effectively, you need to configure your preferred diff tool. This is typically done using <b><I>git config</I></b>:<br><br>Set the default tool globally:<br><I>git config --global diff.tool meld</I><br><br>If Git cannot find your tool automatically, you might need to specify its full path:<br><I>git config --global difftool.meld.path /usr/bin/meld</I><br><br>You can also configure whether to prompt for each file globally:<br><I>git config --global difftool.prompt false</I><br><br>These configurations can be set per repository, globally, or for the current user depending on the <b><I>--local</I></b>, <b><I>--global</I></b>, or <b><I>--system</I></b> options of <b><I>git config</I></b>.


title: HISTORY
content:
Introduced early in Git's development, <b><I>git-difftool</I></b> evolved to provide a more intuitive and visual way to inspect changes, complementing the command-line output of <b><I>git diff</I></b>. Its integration with a wide range of third-party diff applications solidified its role as a key utility for developers preferring graphical interfaces for code comparison, enhancing Git's usability for detailed review tasks.


title: PARAMETERS
content:
<b>--author / --no-author</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes or excludes author-based statistics in the output.<br><br><b>--file / --no-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes or excludes file-based statistics in the output.<br><br><b>--committer / --no-committer</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes or excludes committer-based statistics in the output.<br><br><b>--lines / --no-lines</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes or excludes the total lines changed (added/deleted) in the output.<br><br><b>--count / --no-count</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes or excludes the total commit count in the output.<br><br><b>--summary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays only a summary line without detailed breakdowns per author or file.<br><br><b>--sort <i>&lt;key&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts the output by a specific metric such as <i>lines</i>, <i>commits</i>, or <i>files</i>.<br><br><b>--reverse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverses the sort order, displaying results from lowest to highest.<br><br><b>--since <i>&lt;date&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Considers only commits made after the specified date or time.<br><br><b>--until <i>&lt;date&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Considers only commits made before the specified date or time.<br><br><b>--limit <i>&lt;n&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the output to the top N results based on the current sort order.<br><br><b><i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular file or directory to analyze, restricting the effort calculation to changes within that scope.<br><br>


title: DESCRIPTION
content:
<i>git-effort</i> is a utility that analyzes Git commit history to provide insights into developer contributions and "effort." <br> It typically quantifies this by examining metrics such as the number of lines changed (added/deleted), the total count of commits, and the number of distinct files touched by each author or committer within a specified period or path. <br> This tool helps project managers and team leads understand areas of high activity, identify key contributors, and get a quantitative overview of work distribution. It's often distributed as part of <i>git-extras</i> or similar external utility collections. <br> While "effort" is a heuristic, it offers a useful perspective on code activity.


title: CAVEATS
content:
<i>git-effort</i> is not a standard command included with Git; it typically requires installation of external tools like <i>git-extras</i>. <br> The term "effort" is a heuristic based on quantitative metrics (lines of code, commits) and does not directly measure code quality, complexity, or true productivity. <br> Large refactorings or auto-generated code changes can skew line count metrics, potentially overstating actual effort. <br> Always consider these metrics in context with qualitative assessments.


title: METRICS DEFINED
content:
The command typically quantifies "effort" by aggregating various metrics from the Git history. These commonly include: <b>Lines Changed</b> (sum of additions and deletions), <b>Commit Count</b> (total number of commits made), and <b>Files Touched</b> (number of unique files modified). These metrics provide a numerical representation of activity within the codebase.


title: HISTORY
content:
<i>git-effort</i> gained prominence primarily as a part of the <i>git-extras</i> project, a collection of useful Git scripts that extend its functionality. <br> It emerged from the need for developers and project managers to quickly gauge activity and contribution levels within a Git repository beyond basic commit logs. <br> Its development reflects a community-driven effort to add more analytical capabilities to Git, providing a simple command-line interface for complex historical data aggregation.


title: SYNOPSIS
content:
<i>git fame</i> [<i>--sort=</i><I>key</I>] [<i>--email</i>] [<i>--since=</i><I>date</I>] [<i>--until=</i><I>date</I>] [<i>--by-file</i>] [<i>--branch=</i><I>name</I>] [<i>--exclude=</i><I>pattern</I>] [<i>--incl-merges</i>] [<i>--csv</i>] [<i>--cost</i>] [<i>--loc</i>] [<i>--whitespace</i>] [<I>file_pattern</I>...]


title: PARAMETERS
content:
<b><i>--sort=</i><I>key</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by the specified <i>key</i>. Common values include <b>lines</b> (default), <b>commits</b>, or <b>files</b>.<br><br><b><i>--email</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display authors' email addresses instead of their names.<br><br><b><i>--since=</i><I>date</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit commits to those made after the specified <i>date</i>.<br><br><b><i>--until=</i><I>date</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit commits to those made before the specified <i>date</i>.<br><br><b><i>--by-file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display contributions grouped by file instead of by author.<br><br><b><i>--branch=</i><I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the branch to analyze. Defaults to the current branch.<br><br><b><i>--exclude=</i><I>pattern</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files matching the given <i>pattern</i> from the analysis. Can be used multiple times.<br><br><b><i>--incl-merges</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include merge commits in the analysis. By default, merge commits are often ignored to prevent inflated line counts.<br><br><b><i>--csv</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the results in Comma Separated Value (CSV) format, suitable for programmatic parsing.<br><br><b><i>--cost</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include the 'cost' of file renames and moves in the line counts, treating them as changes.<br><br><b><i>--loc</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use raw lines of code (LOC) count instead of unique lines of code, which might subtract lines on deletion.<br><br><b><i>--whitespace</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore whitespace differences when comparing file versions, focusing only on substantive code changes.<br><br><b><I>file_pattern</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze only files matching the given <i>file_pattern</i>(s). Can be a list of paths or glob patterns.<br><br>


title: DESCRIPTION
content:
The <i>git-fame</i> command provides a summary of contributions by authors in a Git repository, primarily focusing on lines of code (LOC). It analyzes the commit history to determine how many lines each author has added, deleted, or changed. Unlike simple commit counts, <i>git-fame</i> aims to provide a more nuanced view of code ownership and contribution by quantifying the actual lines of code involved. It's often used to get insights into who wrote what, measure team contributions, or identify the primary authors of a project or specific files. The output is typically presented in a tabular format, showing author names, commit counts, and lines of code contributed, with options to sort by various criteria and filter by date or file patterns.<br><br>It's important to note that <i>git-fame</i> is not a part of the core Git distribution but is commonly available as a separate script, often through projects like <i>git-extras</i>.


title: CAVEATS
content:
<i>git-fame</i> is typically a standalone script and not part of the core Git distribution, meaning its availability and exact behavior might vary depending on how it's installed (e.g., via <i>git-extras</i>). Line counting methodologies can also be complex; different tools might yield slightly different LOC counts based on how they handle whitespace, blank lines, renames, and merge commits. The interpretation of 'lines of code' should always consider these nuances.


title: INSTALLATION
content:
Since <i>git-fame</i> is not a core Git command, it typically needs to be installed separately. The most common way to get it is by installing the <b>git-extras</b> package, which includes <i>git-fame</i> along with many other useful Git utilities. Installation methods vary by operating system (e.g., <b>apt install git-extras</b> on Debian/Ubuntu, <b>brew install git-extras</b> on macOS).


title: USAGE AND INTERPRETATION
content:
<i>git-fame</i> provides valuable insights into code contributions, but its output should be interpreted carefully. Metrics like 'lines of code' can be misleading without context, as a large number of lines might represent refactoring, boilerplate, or even deletions. It's best used as one metric among many to understand project dynamics, rather than a sole measure of productivity or value.


title: HISTORY
content:
The <i>git-fame</i> script emerged as a community-contributed tool to address the need for more detailed line-of-code statistics beyond what core Git commands like <i>git shortlog</i> provide. It's not part of the official Git project but has been widely adopted and distributed through various Git utility collections, most notably <i>git-extras</i>, which bundles many useful Git-related scripts. Its development is community-driven, with contributions often focusing on improving line counting accuracy, adding filtering options, and enhancing output formats.


title: PARAMETERS
content:
<b>--depth &lt;n&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the import to a shallow history, including only the last <i>n</i> commits per branch.<br><br><b>--export-marks=&lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Export the generated marks to a specified file, useful for resuming or chaining imports.<br><br><b>--import-marks=&lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Import marks from a specified file, allowing the re-use of object IDs from previous imports.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow <b>fast-import</b> to run even if the repository is not empty, potentially overwriting existing references.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process the input stream but do not write any Git objects or update references.<br><br><b>--show-stats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print performance statistics at the end of the import operation.<br><br><b>--max-pack-size=&lt;n&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum size for generated pack files during the import process.<br><br><b>--big-file-threshold=&lt;n&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize handling of large files by treating them as 'big files' if their size exceeds <i>n</i> bytes.<br><br><b>--cat-blob-fd=&lt;fd&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified file descriptor for cat-blob requests, enabling an external process to provide blob content.<br><br><b>--refmap=&lt;refmap&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply a reference mapping to translate incoming reference names (e.g., <i>refs/heads/*:refs/remotes/origin/*</i>).<br><br><b>--progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display progress messages to standard error during the import.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress non-essential output, including progress messages.<br><br>


title: DESCRIPTION
content:
<b>git fast-import</b> is a highly optimized Git command designed for efficiently importing large amounts of historical data from other version control systems into a Git repository. It operates by reading a specific, stream-based 'fast-import' protocol from standard input, which describes the repository's history in terms of branches, commits, file content, and references. This protocol is designed to be very simple and parseable, allowing for extremely fast ingestion of data, bypassing many of the overheads associated with creating commits and objects one by one.<br><br>It's not a direct converter from other VCSs; rather, it's the <i>target</i> for converters (like git-svn or custom scripts) that translate a foreign VCS's history into the fast-import stream format. This makes <b>git fast-import</b> an indispensable tool for migrating large, complex repositories from systems like SVN, Mercurial, or Perforce into Git, preserving the full commit history, tags, and branches. Its stream-based nature also allows for handling histories larger than available RAM, as data is processed incrementally.


title: CAVEATS
content:
<b>git fast-import</b> expects a specific, stream-based input format. It is not a direct conversion tool for other VCSs; you need a pre-processor or script (like <i>git-svn</i>) to generate the fast-import stream.<br><br>While highly optimized, importing extremely large repositories (gigabytes of data, millions of commits) can still be memory and CPU intensive, especially during the packing phase.<br><br>Error handling for malformed input streams can be challenging, as the process is stream-based and errors might only appear much later.<br><br>It typically works best on an empty or newly initialized repository to avoid conflicts with existing history, though <i>--force</i> can override this.


title: THE FAST-IMPORT PROTOCOL
content:
<b>git fast-import</b> operates on a meticulously defined text-based protocol read from standard input. This protocol consists of commands like <i>blob</i>, <i>commit</i>, <i>tag</i>, <i>reset</i>, <i>checkpoint</i>, and <i>progress</i>, which describe objects (blobs, trees, commits, tags) and how they relate to the repository's history and references. Each command has a specific syntax for defining content, metadata (author, committer, date), parents, and target references. The simplicity and efficiency of this protocol are key to <b>git fast-import</b>'s performance, as it avoids the overhead of complex data structures or object validation during the initial ingestion phase, allowing for raw data to be streamed directly into Git's object database.


title: TYPICAL WORKFLOW
content:
A common workflow for using <b>git fast-import</b> involves three main steps:<br>1. <b>Extraction and Transformation</b>: Use a custom script or a specialized tool (e.g., <i>svn2git</i>, <i>hg-fast-export</i>) to extract the history from the source VCS (e.g., SVN, Mercurial) and transform it into the <b>git fast-import</b> stream format. This often involves handling author mappings, branch/tag naming conventions, and large file strategies.<br>2. <b>Import</b>: Pipe the generated fast-import stream directly into <b>git fast-import</b> in an empty or newly initialized Git repository. For example: <i>cat fast-import-stream.txt | git fast-import</i>.<br>3. <b>Post-Import Optimization</b>: After the import is complete, it's highly recommended to run <i>git gc --prune=now</i> and <i>git repack -ad</i> to optimize the repository's storage, remove unnecessary objects, and ensure efficient access to the newly imported history.


title: HISTORY
content:
<b>git fast-import</b> was introduced very early in Git's development, specifically designed to address the critical need for efficient migration of existing version control histories from other systems. Prior to its existence, importing large projects was a slow and often impractical process. Linus Torvalds himself played a significant role in its design, aiming for a protocol that was simple, stateless, and optimized for speed and large datasets. Its stream-oriented nature allows it to handle histories that far exceed available memory, making it a cornerstone for large-scale migrations from systems like CVS, SVN, and Mercurial into Git, thus contributing significantly to Git's widespread adoption in enterprise environments. The fast-import protocol itself has remained remarkably stable and efficient over the years.


title: SYNOPSIS
content:
<br><i><b>git fetch</b> [<I>options</I>] [<I>repository</I>] [<I>refspec</I>...]<br><b>git fetch</b> [<I>options</I>] --all<br><b>git fetch</b> [<I>options</I>] --prune<br></i><br>


title: PARAMETERS
content:
<b><I>repository</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>The URL or name of the remote repository to fetch from. If omitted, all remotes are used.</i><br><br><br><b><I>refspec</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Specifies what refs to fetch and what local refs to update (e.g., <I>+&lt;src&gt;:&lt;dst&gt;</I>).</i><br><br><br><b><I>--all</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Fetch all remotes defined in your configuration.</i><br><br><br><b><I>--prune</I>, <I>-p</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Remove any remote-tracking branches that no longer exist on the remote.</i><br><br><br><b><I>--tags</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Fetch all tags from the remote.</i><br><br><br><b><I>--no-tags</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Disable automatic tag following; no tags are fetched.</i><br><br><br><b><I>--depth</I> <I>&lt;depth&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Limit the fetch to the specified number of commits from branch tips.</i><br><br><br><b><I>--recurse-submodules</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Recursively fetch all necessary data for submodules.</i><br><br><br><b><I>--force</I>, <I>-f</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Force overwrite of local tracking branches even if they have diverged.</i><br><br><br><b><I>--dry-run</I>, <I>-n</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><i>Show what would be fetched without actually fetching.</i><br><br><br>


title: DESCRIPTION
content:
<br><i>The `git fetch` command is used to download objects and refs from another repository, commonly a remote one configured in your Git setup. It retrieves all the branches and tags from the remote that are not already present in your local repository. Unlike `git pull`, `git fetch` does not automatically merge or rebase the fetched content into your current local branch. Instead, it updates your remote-tracking branches (e.g., `origin/main`, `origin/develop`), allowing you to inspect the changes on the remote without affecting your local working directory or current branch. This makes `git fetch` a safe operation to see what others have pushed. After fetching, you can then choose to merge, rebase, or cherry-pick specific changes into your local branches, giving you more control over integrating remote work.</i><br>


title: CAVEATS
content:
<br><i>Unlike `git pull`, `git fetch` does not automatically update your current local branch or working directory. It only updates your remote-tracking branches (e.g., `origin/main`). To integrate changes into your local branch, you must explicitly run `git merge` or `git rebase` after fetching.<br>Using `--force` can overwrite local remote-tracking branches, even if they have diverged, so use it with caution.</i><br>


title: FETCH_HEAD
content:
<br><i>After a successful `git fetch` operation, information about what was fetched is stored in the `.git/FETCH_HEAD` file. This file records the branch tips that were fetched from the remote repository. Commands like `git pull` use `FETCH_HEAD` to determine what to merge or rebase.</i><br>


title: DEFAULT BEHAVIOR
content:
<br><i>When invoked without a <I>repository</I> or <I>refspec</I>, `git fetch` fetches all remote-tracking branches for all configured remotes that have `fetch` defined in their configuration. It also fetches any tags that point to newly fetched objects. This behavior is generally safe and allows you to see all recent changes on the remote without affecting your local work.</i><br>


title: HISTORY
content:
<br><i>As a fundamental operation for interacting with remote repositories, `git fetch` has been a core command since Git's early days. Its primary role of downloading remote objects and references without modifying the local working directory has remained constant. Subsequent developments have introduced options such as `--prune`, `--depth`, and `--recurse-submodules` to provide more fine-grained control over what gets fetched and how, alongside performance optimizations for large repositories and network operations.</i><br>


title: SEE ALSO
content:
<br><i>git-pull(1)</i><br>, <br><i>git-remote(1)</i><br>, <br><i>git-branch(1)</i><br>, <br><i>git-merge(1)</i><br>, <br><i>git-rebase(1)</i><br>


title: SYNOPSIS
content:
<b>git fetch-pack</b> [--all] [--quiet] [--keep] [--thin] [--no-progress] [--check-self-contained-and-connected] [--dry-run] [--verbose] [--upload-pack=<I>git-upload-pack</I>] [--exec=<I>git-upload-pack</I>] [--depth=<I>depth</I>] [--deepen-since=<I>timestamp</I>] [--deepen-not=<I>revision</I>] [--negotiation-tip=<I>revision</I>] [--max-pack-size=<I>bytes</I>] [--filter=<I>filter-spec</I>] [--ref-delta] <I>repository</I> [<I>ref</I>...]


title: PARAMETERS
content:
<b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch all refs found on the remote, instead of specific ones.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress progress reporting and error messages.<br><br><b>--keep</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not delete the fetched packfile after unpacking. Normally, packfiles are deleted if they are not stored permanently.<br><br><b>--thin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow the remote to send a thin pack, which omits objects that are known to exist locally.<br><br><b>--no-progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show progress status.<br><br><b>--check-self-contained-and-connected</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check that the received pack is self-contained and connected.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't actually fetch anything, just report what would be fetched.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report more details during the fetch process.<br><br><b>--upload-pack=<I>git-upload-pack</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <I>git-upload-pack</I> program on the remote host. Useful if it's not in the default PATH.<br><br><b>--exec=<I>git-upload-pack</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Same as --upload-pack, but implies using SSH protocol.<br><br><b>--depth=<I>depth</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit fetching to a specified number of commits from the tips of the branches. Used for shallow clones.<br><br><b>--filter=<I>filter-spec</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Request a partial clone, filtering objects based on the provided spec (e.g., 'blob:none' to exclude all blobs).<br><br><b>--ref-delta</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow the remote to send ref-delta objects, which can reduce network traffic for large repositories.<br><br><b><I>repository</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL or path to the remote repository.<br><br><b><I>ref</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A list of references (e.g., branch names, commit SHAs) to fetch from the remote repository.<br><br>


title: DESCRIPTION
content:
The <b>git-fetch-pack</b> command is a low-level <I>plumbing</I> command used by other Git commands, such as <I>git fetch</I>, <I>git pull</I>, and <I>git clone</I>, to communicate with a remote repository's <I>git-upload-pack</I> instance.<br><br>Its primary function is to negotiate and transfer Git objects (commits, trees, blobs, and tags) from the remote repository to the local one. It determines which objects are missing locally, requests them from the remote, and receives them, often in the form of a <I>packfile</I>. This process involves a negotiation phase where both sides determine the most efficient way to transfer only the necessary objects.<br><br>Users typically do not invoke <I>git-fetch-pack</I> directly. Instead, they use the higher-level commands that wrap its functionality, providing a more user-friendly interface for common operations like fetching updates or cloning repositories.


title: CAVEATS
content:
<b>git-fetch-pack</b> is a <I>plumbing</I> command, meaning it's part of Git's internal machinery and is generally not intended for direct use by end-users. Improper direct invocation can lead to unexpected behavior or an incomplete understanding of Git's state. It relies heavily on its counterpart, <I>git-upload-pack</I>, on the remote side for successful operation.<br><br>While it provides fine-grained control over the fetching process, higher-level commands like <I>git fetch</I> encapsulate this complexity and are safer and more convenient for most use cases.


title: INTERNAL COMMUNICATION
content:
<b>git-fetch-pack</b> establishes a connection with the remote's <b>git-upload-pack</b> process, which is responsible for serving the requested Git objects. This client-server interaction forms the backbone of Git's network operations.


title: PACKFILE TRANSFER
content:
One of its key functions is the efficient transfer of objects via <I>packfiles</I>. A packfile is a single file containing multiple Git objects (commits, trees, blobs, tags) compressed together, along with an index file for quick lookup. This significantly reduces the overhead of transferring many small objects individually.


title: HISTORY
content:
As a core component of Git's remote communication protocol, <I>git-fetch-pack</I> has been fundamental to Git's design since its early days. It embodies the pack protocol, which was introduced to efficiently transfer Git objects over the network by packaging them into a single, compressed file (<I>packfile</I>). Its evolution has mirrored the development of Git itself, with new options added over time to support features like shallow cloning, partial cloning (object filtering), and improved negotiation strategies to optimize network transfers.


title: PARAMETERS
content:
<b>--env-filter <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><command></i> is evaluated for each commit, allowing modification of environment variables that affect the commit (e.g., <i>GIT_AUTHOR_NAME</i>, <i>GIT_COMMITTER_EMAIL</i>).<br><br><b>--tree-filter <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><command></i> is run after the checkout of the tree for the commit. It allows modification of the files in the working directory before a new commit is created. Useful for adding, removing, or modifying files directly.<br><br><b>--index-filter <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><command></i> is run after the index is populated for the commit. It allows modification of the index without checking out the files, making it generally faster than <i>--tree-filter</i>. Useful for removing files from history (e.g., <i>git rm --cached --ignore-unmatch filename</i>).<br><br><b>--parent-filter <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><command></i> is evaluated for each commit to modify its parent list. Use with extreme care as it can easily corrupt history.<br><br><b>--msg-filter <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><command></i> is run for each commit message, allowing its content to be modified (e.g., using <i>sed</i> to replace text).<br><br><b>--commit-filter <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><command></i> is run for each commit, receiving the original commit ID on standard input. It allows full control over the commit object creation (e.g., skipping commits).<br><br><b>--tag-name-filter <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><command></i> is evaluated for each tag reference, allowing its name to be modified or the tag to be removed (by outputting an empty string).<br><br><b>--subdirectory-filter <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rewrites the history to make the specified <i><path></i> the new project root. Effectively extracts a subdirectory into its own repository.<br><br><b>--prune-empty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes commits that become empty after the filter process (e.g., if all changes are filtered out).<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>git-filter-branch</i> to run even if a <i>refs/original/</i> namespace already exists from a previous run.<br><br><b>--original <namespace></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative namespace to store the original references. By default, it's <i>refs/original/</i>.<br><br><b><rev-list options>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Standard Git revision list options (e.g., <i>--all</i>, <i><branch-name></i>, <i><commit-range></i>) to specify which commits to process. If omitted, it processes all refs.<br><br>


title: DESCRIPTION
content:
<i>git-filter-branch</i> is a powerful command-line tool for rewriting Git repository history. It iterates through all or a specified subset of commits, allowing you to modify them based on various criteria. Common use cases include removing sensitive data or large files from history, changing author information for specific commits, altering commit messages, or extracting a subdirectory into a new, standalone repository.<br><br>While highly flexible, <i>git-filter-branch</i> works by rewriting the entire history, which means it creates new commit IDs for all affected commits and subsequent ones. This makes it a destructive operation that should be used with extreme caution, especially on shared repositories. Its power lies in its ability to apply scriptable filters to every commit in the specified range. For many modern use cases, the newer and often faster <i>git filter-repo</i> is recommended as an alternative.


title: CAVEATS
content:
History rewriting is a destructive operation that changes commit IDs. <b>NEVER</b> use <i>git-filter-branch</i> on a repository that is publicly shared or that others have cloned, unless you can coordinate with all collaborators to ensure they re-clone or rebase their work on the new history. Failure to do so will lead to significant repository divergence and merge conflicts. The command can be very slow for large repositories and complex filters. It stores a backup of original refs in <i>refs/original/</i>, which can consume significant disk space until manually deleted. Always back up your repository before running this command.


title: PERFORMANCE CONSIDERATIONS
content:
<i>git-filter-branch</i> can be extremely slow, particularly when using <i>--tree-filter</i>, as it checks out every commit's contents. For operations that only modify the index or metadata, <i>--index-filter</i> or <i>--env-filter</i> are significantly faster. For large repositories or complex filtering tasks, consider using <i>git filter-repo</i>, which is designed for better performance.


title: POST-REWRITING CLEANUP
content:
After successfully running <i>git-filter-branch</i> and pushing the rewritten history (which usually requires a <i>git push --force-with-lease</i> or <i>git push --force</i>), it's crucial to clean up your local repository. This involves:<br>1. Deleting the backup refs: <i>git update-ref -d refs/original/refs/heads/master</i> (and for other branches/tags)<br>2. Running garbage collection: <i>git reflog expire --expire=now --all && git gc --prune=now</i><br>These steps remove the old, unreferenced objects and significantly reduce repository size.


title: HISTORY
content:
<i>git-filter-branch</i> was one of the earliest and most versatile tools available in Git for advanced history manipulation. It emerged from the need to address common repository issues like removing inadvertently committed large files or sensitive data, which cannot be undone by simple reverts. For many years, it was the go-to utility for complex history rewrites. However, its performance (especially on large repositories) and sometimes intricate scripting requirements led to the development of faster and more user-friendly alternatives like <i>git filter-repo</i>, which is written in Python and often preferred today. Despite this, <i>git-filter-branch</i> remains a core Git command, still functional for specific, nuanced use cases or when external tools are not an option.


title: PARAMETERS
content:
<b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show what would be done without actually modifying the repository.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override various safety checks, such as operating on a dirty repository or overwriting existing backups.<br><br><b>--path <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter by file paths; only include commits that touch these specified paths.<br><br><b>--invert-paths</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invert the meaning of --path, effectively excluding the specified paths.<br><br><b>--strip-blobs-bigger-than <size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove blobs (files) larger than the specified size from history.<br><br><b>--replace-text <old:new></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replace occurrences of text across all files in the repository's history.<br><br><b>--commit-callback <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a custom Python command or script on each commit object being processed.<br><br><b>--blob-callback <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a custom Python command or script on each blob (file content) object.<br><br><b>--subdirectory-filter <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract a subdirectory into the root of the new repository, discarding other content.<br><br><b>--to-subdirectory-filter <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Move all contents of the current repository into a new subdirectory.<br><br><b>--mailmap</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply a .mailmap file to clean up and normalize author/committer identities.<br><br><b>--preserve-empty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep commits that become empty after filtering, instead of dropping them.<br><br>


title: DESCRIPTION
content:
<i>git-filter-repo</i> is a sophisticated tool for rewriting Git repository history, designed as a modern, safer, and faster alternative to the older <i>git filter-branch</i> command. It allows users to perform complex history manipulation tasks such as removing sensitive files or data from all commits, excising large binary files accidentally committed, splitting or combining repositories, and modifying commit metadata like author or committer information.<br><br>Written in Python, it prioritizes safety by default, often creating backups and refusing to operate on dirty repositories, thereby reducing the risk of accidental data loss during the rewriting process. Its flexibility comes from a powerful filtering engine that can apply various transformations to commits, trees, blobs, and references.


title: CAVEATS
content:
<ul><li><b>Destructive Operation:</b> Rewrites history, changing commit SHAs. Always back up your repository before use.</li><li><b>Requires Git 2.22+:</b> Depends on newer Git features for optimal performance and safety.</li><li><b>Python Dependency:</b> As it's written in Python, a compatible Python interpreter is required to run the command.</li><li><b>Shared Repositories:</b> Not suitable for public repositories where history has already been shared. All collaborators will need to re-clone or force update their repositories.</li></ul>


title: SAFETY FEATURES
content:
<i>git-filter-repo</i> incorporates several robust safety mechanisms. It automatically creates a backup of the original repository state in a <i>filter-repo/</i> directory before performing any changes. It also refuses to operate on a dirty working directory by default, preventing accidental data loss, and requires explicit use of the <b>--force</b> option for potentially dangerous operations.


title: CALLBACKS
content:
A powerful and flexible aspect of <i>git-filter-repo</i> is its extensive callback system. Users can provide custom Python scripts (callbacks) that are executed for various Git objects such as blobs, trees, commits, tags, references, and even individual path entries. This allows for highly specific, complex, and programmable history transformations that are not covered by the standard command-line options, enabling fine-grained control over the rewriting process.


title: HISTORY
content:
<i>git-filter-repo</i> was created by Eli Schwartz (newren), a Git contributor, as a modern and more efficient successor to the older, often problematic <i>git filter-branch</i>. Recognizing the shortcomings of <i>git filter-branch</i> (slow, complex, prone to errors), this new tool was developed to leverage modern Git features and a robust Python-based architecture. First publicly released around 2020, it quickly gained prominence due to its speed, built-in safety features (like automatic backups and dirty repository checks), and a flexible callback system, becoming the recommended tool for complex history rewriting tasks by the Git community.


title: SYNOPSIS
content:
<code>git flow <b><I>subcommand</I></b> [options]</code><br><br><i>Examples:</i><br><code>git flow <b><I>init</I></b> [-d]</code><br><code>git flow <b><I>feature</I></b> <b><I>start</I></b> <b><I>name</I></b> [base]</code><br><code>git flow <b><I>release</I></b> <b><I>finish</I></b> <b><I>version</I></b> [-s] [-f]</code>


title: PARAMETERS
content:
<b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new git-flow repository, configuring default branch names and creating `develop`.<br><br><b>feature</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages feature branches. Allows starting new features, finishing them (merging into develop), listing, and publishing.<br><br><b>release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages release branches. Facilitates preparing new production releases, including tagging and merging into `main`/`develop`.<br><br><b>hotfix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages hotfix branches for immediate production fixes, branched from `main`/`master`.<br><br><b>support</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages long-running support branches for older releases, branched from `main`/`master`.<br><br><b>publish</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Publishes a local git-flow branch (feature, release, hotfix) to the remote repository.<br><br><b>track</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tracks a git-flow branch (feature, release, hotfix) from the remote repository locally.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed git-flow version.<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages git-flow configuration settings for the repository.<br><br>


title: DESCRIPTION
content:
Git-flow is a set of Git extensions that provides high-level repository operations for Vincent Driessen's branching model. This model defines a strict but robust way of managing releases, features, and hotfixes through dedicated branches. It standardizes the workflow around `main` (or `master`) and `develop` branches as core, complemented by `feature` branches for development, `release` branches for preparing new releases, and `hotfix` branches for quick production fixes. Git-flow automates many of the steps involved in this workflow, such as creating, finishing, merging, and deleting these specialized branches, as well as handling tagging. It aims to streamline collaboration and ensure a consistent branching strategy across teams, making complex release cycles more manageable. While opinionated, it's widely adopted for projects requiring predictable and formalized release processes.


title: CAVEATS
content:
<ul><li><b>Rigidity:</b> Git-flow implements a very specific and opinionated branching model. While robust, it might be overly complex or restrictive for simpler projects or teams adopting more flexible continuous delivery practices.</li><li><b>Learning Curve:</b> Teams new to git-flow might require time to understand and adapt to its structured workflow.</li><li><b>Branch Name Dependence:</b> It relies on specific branch naming conventions (e.g., `feature/`, `release/`, `hotfix/`) which are configured during initialization.</li></ul>


title: CORE BRANCHING MODEL
content:
Git-flow defines two main long-lived branches:<br><b>master</b> (or <b>main</b>): Holds the official release history, reflecting what's in production.<br><b>develop</b>: Integrates new features and prepares for the next release, serving as the branch for ongoing development.


title: AUXILIARY BRANCHES
content:
It also uses short-lived, supporting branches for specific purposes:<br><b>feature/</b>: For developing new features in isolation, branched from `<b>develop</b>` and merged back into it.<br><b>release/</b>: For preparing a new software release, branched from `<b>develop</b>` and merged into both `<b>main</b>` and `<b>develop</b>`.<br><b>hotfix/</b>: For quickly patching production issues, branched from `<b>main</b>` and merged into both `<b>main</b>` and `<b>develop</b>`.


title: HISTORY
content:
The git-flow branching model was first proposed by Vincent Driessen in his 2010 blog post, "<I>A successful Git branching model</I>". This model quickly gained popularity for its clear separation of concerns in development, release preparation, and urgent fixes. The `git-flow` command-line extension, developed by Peter van der Hagen, provides a practical implementation of this model, automating many of its complex steps. Its widespread adoption helped standardize a common approach to branching strategies in Git, especially for projects with distinct release cycles.


title: PARAMETERS
content:
<b>-m <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the primary merge description from <I>file</I>. This file typically contains the branch names and potentially a merge message header prepared by <I>git merge</I>.<br><br><b>-F <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads additional log message content from <I>file</I>. This is typically used in scenarios like squash merges, where a specific log message needs to be included in the merge commit.<br><br><b><base-description></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A short, user-friendly description of the base branch or commit that is being merged into. This is usually automatically generated by <I>git merge</I>.<br><br><b><branch-description></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A short, user-friendly description of the branch or commit that is being merged. This is also typically automatically generated by <I>git merge</I>.<br><br>


title: DESCRIPTION
content:
<I>git-fmt-merge-msg</I> is an internal Git <b>plumbing</b> command primarily used by <I>git merge</I> to generate the default merge commit message. It is not typically invoked directly by end-users. The command takes descriptions of the merged branches and, optionally, pre-existing merge message content and conflict information, then formats them into a standard merge commit log. It handles different merge scenarios, such as regular merges, fast-forward merges, and squash merges, adapting the message accordingly.<br><br>It often reads details from internal Git files like <I>.git/MERGE_MSG</I>, <I>.git/MERGE_RR</I>, and <I>.git/MERGE_RR_OMIT</I> to construct the final message, which includes details about the merged branches and any detected merge conflicts. Its purpose is to ensure a consistent and informative default message for merge commits, reducing manual effort for users.


title: CAVEATS
content:
This command is an internal Git <b>plumbing</b> command. It is typically invoked automatically by higher-level Git commands like <I>git merge</I> and is not intended for direct user interaction. As an internal command, its interface or behavior might change in future Git versions without strict backward compatibility guarantees, although it has been stable for a long time. Users should rely on <I>git merge</I> to generate their merge commit messages rather than trying to manually execute this command.


title: INTERNAL PLUMBING COMMAND
content:
<I>git-fmt-merge-msg</I> is categorized as a "plumbing" command in Git. Plumbing commands are low-level commands that perform specific operations and are designed to be used as building blocks by "porcelain" (user-facing) commands or scripts. This means it is usually invoked by <I>git merge</I> behind the scenes, rather than directly by a user.


title: MERGE MESSAGE GENERATION LOGIC
content:
The command is responsible for constructing the default merge commit message based on information stored in the <I>.git</I> directory. This includes files like <I>.git/MERGE_MSG</I> (which contains the raw message for the merge), <I>.git/MERGE_RR</I> (details about merge conflict resolution), and <I>.git/MERGE_RR_OMIT</I> (paths that were removed due to conflicts). It intelligently combines these pieces of information to produce a readable and informative commit message that summarizes the merge operation and any conflicts.


title: HISTORY
content:
The <I>git-fmt-merge-msg</I> command has been a fundamental part of Git's internal plumbing since the early days of the <I>git merge</I> command. It was introduced to provide a consistent and automated way to generate default merge commit messages. Over time, its core function of formatting merge descriptions into a commit message has remained a foundational piece of Git's merge workflow, adapting to new merge strategies or features (like squash merges) as they were introduced, but its fundamental role has been stable.


title: SYNOPSIS
content:
<b>git for-each-ref</b> [<I>options</I>] [<I>pattern</I>...]<br><br>Commonly used options:<br><b>git for-each-ref</b> [--count=<I>n</I>] [--format=<I>format</I>] [--sort=<I>key</I>] [--color[=<I>when</I>]] [--points-at=<I>object</I>] [--merged[=<I>object</I>]] [<I>pattern</I>...]


title: PARAMETERS
content:
<b>--count=<n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of references output to the first <I>n</I> items after sorting.<br><br><b>--shell | --perl | --python | --tcl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate output suitable for shell, Perl, Python, or Tcl scripts by quoting values appropriately.<br><br><b>--points-at=<object></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only references that point to the given <I>object</I> (commit, tree, blob, or tag).<br><br><b>--merged[=<object>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show references that are merged into the specified <I>object</I> (defaults to HEAD if not provided).<br><br><b>--no-merged[=<object>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show references that are <I>not</I> merged into the specified <I>object</I>.<br><br><b>--contains[=<object>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show references whose commit (if applicable) contains the specified <I>object</I>.<br><br><b>--no-contains[=<object>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show references whose commit (if applicable) does <I>not</I> contain the specified <I>object</I>.<br><br><b>--color[=<when>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Colorize the output. <I>when</I> can be 'always', 'never', or 'auto' (default).<br><br><b>--format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A string defining the output format for each reference. It uses placeholders (e.g., <b>%(refname)</b>, <b>%(objectname)</b>) which are substituted with reference data. See 'Format Placeholders' section for details.<br><br><b><pattern>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more patterns to limit the references shown. Patterns match reference names (e.g., 'refs/heads/*', 'refs/tags/*').<br><br><b>--sort=<key></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A field to sort the output by. Prefix with '-' for descending order (e.g., '-committerdate'). Common keys include 'refname', 'objecttype', 'objectsize', 'committerdate'. See 'Sorting Keys' section for details.<br><br><b>--omit-empty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print a newline for lines where the format expands to an empty string.<br><br><b>--ignore-case</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore case when matching patterns.<br><br>


title: DESCRIPTION
content:
<b>git-for-each-ref</b> is a versatile Git plumbing command designed to iterate over and display information about Git references (like branches, tags, remote-tracking branches, and stashes). It provides highly customizable output formats, making it invaluable for scripting and generating tailored reports from a Git repository.<br><br>Unlike <b>git show-ref</b> which simply lists references, or <b>git log</b> which focuses on commits, <b>git for-each-ref</b> offers granular control over <i>what</i> information about each reference is displayed and <i>how</i> it is formatted. Users can specify a format string using various placeholders to extract details such as the reference name, object ID it points to, type of object, committer/author details for annotated tags or branch tips, and more.<br><br>The command also supports powerful filtering options, allowing users to select references based on patterns, whether they are merged into a specific branch, or if they contain a particular commit. Additionally, the output can be sorted by various criteria like creation date, name, or committer date, further enhancing its utility for complex automation tasks and repository analysis.


title: CAVEATS
content:
Using complex <b>--format</b> strings, especially with nested dereferencing or conditional formatting, can become difficult to read and debug.<br><br>When using the command in shell scripts, proper quoting and escaping of the <b>--format</b> string and any embedded newlines or special characters is crucial to avoid parsing issues.<br><br>Performance might be affected in extremely large repositories or when sorting by certain object attributes that require extensive object parsing (e.g., <b>objectsize</b> for all refs).


title: FORMAT PLACEHOLDERS
content:
<i>Key to highly customized output.</i><br>The <b>--format</b> option accepts a string with placeholders that expand to specific information about each reference. Some commonly used placeholders include:<br><ul><li><b>%(refname)</b>: The full name of the reference (e.g., "refs/heads/main", "refs/tags/v1.0").</li><li><b>%(refname:short)</b>: The shortened reference name (e.g., "main", "v1.0").</li><li><b>%(objectname)</b>: The SHA-1 or object ID the reference points to.</li><li><b>%(objecttype)</b>: The type of object (commit, tree, blob, tag) the reference points to.</li><li><b>%(objectsize)</b>: The size of the object pointed to by the reference.</li><li><b>%(committerdate)</b>: The committer date of the commit object (for branches) or annotated tag object. Various format options are available, e.g., <b>%(committerdate:relative)</b>, <b>%(committerdate:iso)</b>.</li><li><b>%(authorname)</b>, <b>%(authoremail)</b>, <b>%(committername)</b>, <b>%(committeremail)</b>: Author/committer details for the associated commit or tag object.</li><li><b>%(upstream)</b>: The name of the upstream branch.</li><li><b>%(HEAD)</b>: Displays '<i>*</i>' if the reference is currently HEAD, otherwise a space.</li><li><b>%(symref)</b>: The symbolic ref that this ref points to, if any.</li><li><b>%(subject)</b>, <b>%(body)</b>, <b>%(contents)</b>: Contents of the commit or tag message.</li></ul>Placeholders can be dereferenced using <b>%(<field>):<atom></b> syntax (e.g., <b>%(objectname:short)</b> or <b>%(committerdate:relative)</b>).


title: SORTING KEYS
content:
<i>Control the order of output.</i><br>The <b>--sort</b> option allows sorting the output by various keys. Common keys include:<br><ul><li><b>refname</b>: Sort by the full reference name (default).</li><li><b>version:refname</b>: Sort refname in version order (e.g., for tags like v1.0, v2.0, v1.10).</li><li><b>objecttype</b>: Sort by the type of object the ref points to.</li><li><b>committerdate</b>: Sort by the committer date of the pointed-to object.</li><li><b>creatordate</b>: For tags, the tagger date; for branches, the committer date of the commit.</li></ul>Any field available as a placeholder (e.g., <b>objectsize</b>, <b>authorname</b>) can generally be used as a sort key. Prefix with '<i>-</i>' for descending order (e.g., <b>--sort=-committerdate</b>).


title: HISTORY
content:
<b>git-for-each-ref</b> has been a staple in Git's plumbing command set since early versions, providing a foundational tool for scripting and automating tasks related to Git references. Its design reflects Git's philosophy of providing low-level, composable commands that can be combined to achieve complex operations. Over time, the command has evolved with the addition of more sophisticated filtering options (like <b>--merged</b> and <b>--contains</b>) and a continuously expanding set of format placeholders, making it increasingly powerful for custom reporting and repository analysis. Its utility has grown significantly as Git repositories have become larger and more complex, demanding more flexible ways to query reference information.


title: SYNOPSIS
content:
git-for-each-repo [--path <I>directory</I>] --exec <I>command</I> [--dry-run] [--verbose] [--exclude <I>pattern</I>]


title: PARAMETERS
content:
<b>--path <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the root directory to begin searching for Git repositories. If omitted, the current working directory is used.<br><br><b>--exec <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The shell command to execute within each discovered Git repository. This is typically a Git command (e.g., <I>git status</I>, <I>git pull</I>) or any other shell command.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a simulation: it lists the repositories that would be processed and the commands that would be executed, without actually running them.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, showing additional details such as the path of each repository before executing the command.<br><br><b>--exclude <I>pattern</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A pattern to exclude directories from the search for Git repositories. This can be useful to skip specific subdirectories or repositories.<br><br>


title: DESCRIPTION
content:
The <I>git-for-each-repo</I> command is not a standard Git utility, but rather a common pattern implemented as a custom shell script or part of a larger repository management tool. Its primary purpose is to automate tasks across multiple independent Git repositories located within a specified directory hierarchy.<br><br>Typically, this command works by recursively searching for Git repository directories (those containing a <I>.git</I> folder) starting from a given path. For each repository found, it then executes a user-defined shell command within that repository's working directory.<br><br>This functionality is incredibly useful for system administrators, developers managing monorepos without using Git submodules, or anyone needing to perform bulk operations like fetching updates, checking statuses, or analyzing branches across numerous projects. While its exact implementation can vary, the core idea remains consistent: simplify repetitive Git operations by iterating through a collection of repositories.


title: CAVEATS
content:
This command is not a standard, officially distributed Git command. It is most often a custom script written by users or bundled with specific development environments. Therefore, its availability, exact syntax, and behavior can vary significantly depending on its implementation. Users should verify its source and functionality before relying on it, especially when executing arbitrary commands.


title: TYPICAL IMPLEMENTATION
content:
Most implementations of <I>git-for-each-repo</I> use shell scripting to recursively find directories containing a <I>.git</I> subdirectory and then execute a command within each found directory. A common pattern involves <B>find . -type d -name '.git' -print0 | xargs -0 -I {} sh -c 'cd "$(dirname {})" && <command>'</B>.


title: SECURITY CONSIDERATIONS
content:
Since this command executes arbitrary shell commands within multiple directories, it's crucial to be aware of the security implications. Always ensure the source of the script is trusted and carefully review the <B>--exec</B> command to prevent unintended or malicious actions, especially when running with elevated privileges.


title: HISTORY
content:
The concept behind <I>git-for-each-repo</I> emerged from the common need to manage and operate on multiple independent Git repositories within a single project directory or across a development environment. Lacking a built-in Git command for this specific purpose (beyond submodules), developers and system administrators began creating their own shell scripts. These scripts typically leverage standard Unix tools like <B>find</B> and <B>xargs</B> to locate Git repositories and execute commands within them. While no single official history exists, its widespread adoption as a custom script reflects a persistent user demand for streamlined multi-repository operations.


title: SYNOPSIS
content:
Since 'git-force-clone' is not a native command, there's no official synopsis. <br>However, the conceptual 'force clone' operation is typically performed by combining standard commands:<br><br><code><b>rm -rf <i>&lt;target_directory&gt;</i> && git clone <i>&lt;repository_url&gt;</i> [<i>&lt;target_directory&gt;</i>]</b></code>


title: PARAMETERS
content:
<b><i>&lt;target_directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The local path where the repository should be cloned. For the <code>rm -rf</code> command, this is the directory to be removed. For <code>git clone</code>, it's the target path for the new repository. If omitted for <code>git clone</code>, the repository's name is used.<br><br><b><i>&lt;repository_url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the Git repository to be cloned (e.g., HTTPS, SSH, Git protocol). This parameter applies to the <code>git clone</code> part of the operation.<br><br><b><i>--bare</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(git clone option)</i> Clone a bare repository (no working directory), useful for central repositories. This option applies to the <code>git clone</code> part.<br><br><b><i>--branch &lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(git clone option)</i> Instead of the default 'HEAD', clone the tip of the specified branch. This option applies to the <code>git clone</code> part.<br><br><b><i>--single-branch</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(git clone option)</i> Clone only the history leading to the tip of a single branch, reducing download size. This option applies to the <code>git clone</code> part.<br><br><b><i>--depth &lt;number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(git clone option)</i> Create a shallow clone with a history truncated to the specified number of commits. This option applies to the <code>git clone</code> part.<br><br>


title: DESCRIPTION
content:
The command 'git-force-clone' is <i>not a standard or native command</i> within the Git version control system. While Git offers powerful capabilities, it prioritizes data integrity and typically requires explicit actions for potentially destructive operations. The term 'force clone' often refers to a conceptual operation or a user-defined script/alias that aims to ensure a fresh, clean clone of a Git repository, typically by <br><i>forcibly removing an existing local directory before executing a standard <code>git clone</code> command</i>. <br><br>Standard <code>git clone</code> behavior is to fail if the target directory already exists and is not empty, preventing accidental overwrites. Therefore, achieving a 'force clone' effect usually involves a two-step process: first, deleting the existing local repository directory (e.g., using <code>rm -rf</code> on Linux/Unix-like systems), and then performing a regular <code>git clone</code> operation into the now-empty or non-existent path. This distinction is crucial to understand to prevent unintended data loss.


title: CAVEATS
content:
The primary caveat of attempting a 'force clone' is the <br><b><i>potential for irreversible data loss</i></b>. <br>Using commands like <code>rm -rf</code> to delete an existing directory will permanently remove all its contents, including any uncommitted changes, untracked files, or local branches that were not pushed to a remote. <br><br>Always ensure you have backed up or pushed any important work before performing such a destructive operation. <br><br>It's also important to remember that 'force cloning' addresses issues with the local workspace, not with the remote repository itself. Git's design prioritizes safety, so operations that could lead to data loss require explicit user confirmation or specific flags, like <code>--force</code> for <code>git push</code>, but not for <code>git clone</code>.


title: ACHIEVING A 'FORCE CLONE' EFFECT
content:
To achieve what is conceptually understood as a 'force clone', users typically execute two separate commands: <br><br>1. <b>Remove the existing directory:</b> <br><code><b>rm -rf <i>&lt;target_directory&gt;</i></b></code> <br>   This command recursively and forcibly removes the specified directory without prompting. <br><br>2. <b>Perform a fresh clone:</b> <br><code><b>git clone <i>&lt;repository_url&gt;</i> [<i>&lt;target_directory&gt;</i>]</b></code> <br>   This command then creates a new, clean clone of the repository. <br><br>This sequence ensures that any previous, potentially corrupted or problematic local state is completely discarded before a fresh copy is obtained from the remote.


title: HISTORY
content:
Git's development has always emphasized <br><i>data integrity and preventing accidental data loss</i>. <br>The <code>git clone</code> command, introduced early in Git's history, was designed to create a new, independent copy of a repository. Its intentional behavior of failing if the target directory already exists prevents users from inadvertently overwriting existing work or valuable data. <br><br>The concept of 'force' in Git usually applies to operations that overwrite remote history (e.g., <code>git push --force</code>) or local working directory changes (e.g., <code>git reset --hard</code>, <code>git clean -f</code>). The absence of a built-in 'force' option for <code>git clone</code> reflects this design philosophy, pushing users towards explicit and conscious actions when dealing with potentially destructive clean-up tasks.


title: SYNOPSIS
content:
<b>git fork</b> [<b>--no-remote</b>] [<b>--ssh</b>] [<b>--no-clone</b>] [<b>--login</b>] [<b>&lt;user&gt;/&lt;repository&gt;</b> | <b>&lt;repository_url&gt;</b>] [<b>&lt;directory&gt;</b>]<br><br>The <b>&lt;user&gt;/&lt;repository&gt;</b> format is a common shorthand for repositories on platforms like GitHub. If <b>&lt;repository&gt;</b> is omitted, it attempts to infer it from the current working directory's remote. <b>&lt;directory&gt;</b> specifies the local folder name for the clone.


title: PARAMETERS
content:
<b><b>&lt;user&gt;/&lt;repository&gt;</b> | <b>&lt;repository_url&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target repository to fork. Can be specified as <b>owner/repo</b> (e.g., <b>octocat/Spoon-Knife</b>) or a full URL (e.g., <b>https://github.com/octocat/Spoon-Knife.git</b>).<br><br><b><b>&lt;directory&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. The local directory name to clone the forked repository into. If omitted, the repository name is used.<br><br><b><b>--no-remote</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents adding the original repository as an <b>upstream</b> remote after cloning.<br><br><b><b>--ssh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the SSH protocol for cloning the repository instead of HTTPS.<br><br><b><b>--no-clone</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forks the repository on the remote platform but does <i>not</i> clone it to the local machine.<br><br><b><b>--login</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts for login credentials (e.g., GitHub username and password/token) to authenticate with the remote hosting service.<br><br>


title: DESCRIPTION
content:
The <b>git-fork</b> command is an external utility, commonly provided as part of the <b>git-extras</b> collection, designed to streamline the process of forking a remote Git repository, typically on platforms like GitHub. Instead of manually navigating to the platform, forking the repository, and then cloning the new fork, <b>git-fork</b> automates these steps.<br><br>When executed, it first attempts to create a fork of the specified repository under your account on the remote hosting service. Once the fork is successfully created, it then automatically clones your newly forked repository to your local machine. Furthermore, it often adds the original repository as a new remote, typically named <b>upstream</b>, allowing for easy synchronization and pulling changes from the original source. This command significantly simplifies the setup for collaborative development workflows, making it easier for contributors to work on projects by providing a dedicated, personal copy of the repository.


title: CAVEATS
content:
The <b>git-fork</b> command is <i>not</i> a native Git command; it typically requires the <b>git-extras</b> package (or a similar external script) to be installed on your system. Its functionality is primarily geared towards and tested with Git hosting platforms like GitHub, and its behavior with other platforms (e.g., GitLab, Bitbucket) may vary or require specific configurations or plugins. For successful operation, proper authentication (e.g., via GitHub Personal Access Token or SSH keys) must be set up with your Git hosting provider.


title: DEPENDENCIES
content:
This command relies on the <b>git-extras</b> package being installed on your system. Without it, <b>git fork</b> will not be recognized as a valid Git command.


title: PLATFORM SUPPORT
content:
While conceptually applicable to any Git hosting service supporting forking, <b>git-fork</b> (as part of <b>git-extras</b>) is primarily optimized for and most reliably works with GitHub.


title: HISTORY
content:
The <b>git-fork</b> command emerged as part of the broader <b>git-extras</b> project, a community-driven effort to extend Git's capabilities with frequently requested or workflow-enhancing commands. Its development reflects the increasing popularity of distributed version control systems and collaborative platforms like GitHub. It was created to address the common pattern of forking a repository, cloning the fork, and setting up an upstream remote, which previously involved multiple manual steps. By automating this sequence, <b>git-fork</b> significantly improved the onboarding experience for new contributors to open-source projects and streamlined the maintenance of personal forks.


title: SEE ALSO
content:
<b>git-clone(1)</b>, <b>git-remote(1)</b>, <b>git-extras(7)</b>, <b>hub(1)</b> <i>(GitHub CLI tool, often used for similar workflows)</i>


title: PARAMETERS
content:
<b><b>-o &lt;dir&gt;</b> / <b>--output-directory=&lt;dir&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where the generated patch files should be stored. If not provided, patches are created in the current directory.<br><br><b><b>-&lt;n&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats the last <i>&lt;n&gt;</i> commits on the current branch as patches. For example, <i>git format-patch -3</i> will create patches for the last three commits.<br><br><b><b>--stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the generated patches to standard output instead of creating individual files. This is useful for piping the output to other commands.<br><br><b><b>--subject-prefix=&lt;prefix&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the prefix for the subject line of the patches (default is <i>PATCH</i>). For instance, <i>--subject-prefix="RFC PATCH"</i>.<br><br><b><b>--cover-letter</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates an additional file (named <i>0000-*</i>) serving as a cover letter for the entire patch series. This file contains the project's shortlog and can be edited to include an introduction or motivation for the series.<br><br><b><b>--attach</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats the patch as a base64 encoded attachment suitable for email clients. This is an alternative to the default inline patch format.<br><br><b><b>--numbered</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures the patches are numbered sequentially (e.g., <i>0001-*</i>, <i>0002-*</i>). This is often the default behavior when generating multiple patches.<br><br><b><b>--start-number=&lt;n&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the starting number for the patch filenames. Useful when splitting a large series or resubmitting parts of it.<br><br><b><b>--thread</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <i>In-Reply-To</i> and <i>References</i> headers to the emails, aiding in email client threading. This groups related patches in email clients.<br><br><b><b>--signature=&lt;sig&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends a <i>Signed-off-by:</i> line to the commit message with the specified signature. If <i>&lt;sig&gt;</i> is omitted, it defaults to the committer's name and email.<br><br><b><b>--ignore-submodules</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores changes to submodules when generating patches. Useful if submodule changes are handled separately or irrelevant to the patch series.<br><br>


title: DESCRIPTION
content:
<i>git format-patch</i> is a core Git command used to prepare patches from a specified range of Git commits. These patches are specifically formatted to be suitable for email submission, commonly to a mailing list, adhering to conventions that allow tools like <i>git am</i> to apply them cleanly. Each commit in the specified range is typically output as a separate, sequentially numbered file (e.g., <i>0001-Subject.patch</i>, <i>0002-Another-Subject.patch</i>).<br><br>The generated patch files include not only the diff of changes introduced by the commit but also essential metadata such as the commit message, author details, and commit date, all structured with appropriate email headers. This makes <i>git format-patch</i> an indispensable tool for projects, like the Linux kernel, that rely on a mailing list-centric development workflow. It offers extensive options to customize output filenames, subject prefixes, numbering, and to generate ancillary files like cover letters, ensuring flexibility for various submission requirements.


title: CAVEATS
content:
<i>git format-patch</i> is optimized for generating patches for email-based workflows, particularly for consumption by <i>git am</i>. While it generates standard diffs, its primary strength lies in adding necessary email headers and formatting to ensure smooth application by the recipient's Git tools. For applying patches locally, <i>git apply</i> or the general <i>patch(1)</i> command might be more direct, but <i>git am</i> is specifically designed to handle patches generated by <i>format-patch</i>.<br><br>Users should also be mindful of character encoding when dealing with non-ASCII commit messages or author names, and may need to use options like <i>--encode-email-headers</i> to ensure patches are correctly parsed by recipients across different systems.


title: COMMON USAGE PATTERNS
content:
Understanding common <i>&lt;revision-range&gt;</i> arguments is key to effectively using <i>git format-patch</i>:<br><br><b>1. Generate patches for the last N commits:</b><br><i>git format-patch -N</i><br>This creates N patch files for the N most recent commits on your current branch. For example, <i>git format-patch -1</i> generates a patch for only the very last commit.<br><br><b>2. Generate patches between two points:</b><br><i>git format-patch &lt;start-commit&gt;..&lt;end-commit&gt;</i><br>This generates patches for all commits *after* <i>&lt;start-commit&gt;</i> *up to and including* <i>&lt;end-commit&gt;</i>. A common use case is <i>git format-patch main..HEAD</i>, which generates patches for all commits on your current branch that are not present on the <i>main</i> branch.<br><br><b>3. Generate patches for all commits on a specific branch not on another:</b><br><i>git format-patch &lt;base-branch&gt; &lt;topic-branch&gt;</i><br>This generates patches for all commits on <i>&lt;topic-branch&gt;</i> that are not reachable from <i>&lt;base-branch&gt;</i>.<br><br><b>4. Output to a specific directory:</b><br><i>git format-patch -o patches/ my_feature_branch..</i><br>This directs all generated patch files into the <i>patches/</i> subdirectory, which is useful for organizing multiple patch series or preparing them for sending.


title: HISTORY
content:
<i>git format-patch</i> has been a core component of Git since its early days, reflecting Git's origins in Linux kernel development, which heavily relies on email-based patch submissions for distributed collaboration. It provides the essential bridge between local Git repositories and development via mailing lists. Its evolution has focused on improving header formatting, supporting email threading (e.g., with <i>--thread</i>), and handling various edge cases related to large patch series and character encodings. It remains a stable, mature, and frequently used command in projects with email-centric workflows.


title: SYNOPSIS
content:
<b>git fresh-branch</b> [<i>OPTIONS</i>] <i>&lt;new-branch-name&gt;</i> [<i>&lt;base-branch-name&gt;</i>]


title: PARAMETERS
content:
<b><i>&lt;new-branch-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired name for the new branch to be created. This is a mandatory argument.<br><br><b><i>&lt;base-branch-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The existing branch from which to create the new branch (e.g., <b>main</b>, <b>master</b>, <b>develop</b>). If not specified, the command typically defaults to a common base branch (often <b>main</b> or <b>master</b>) after pulling updates.<br><br><b><b>-n</b>, <b>--no-push</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the command from automatically pushing the newly created branch to the remote repository. The branch will only be created locally.<br><br>


title: DESCRIPTION
content:
<i>git-fresh-branch</i> is a convenient wrapper script for Git that streamlines the process of creating a new branch. It typically starts by ensuring your base branch (e.g., <b>main</b> or <b>master</b>) is up-to-date by pulling the latest changes. It then creates and checks out a new branch from this refreshed base. Optionally, it can immediately push the newly created branch to the remote repository, setting it up for tracking.<br><br>This command saves time and reduces common errors by automating several standard Git operations into a single, intuitive command. It's especially useful for maintaining a clean branch history and quickly starting new features or bug fixes.


title: CAVEATS
content:
This is typically a community-contributed script and not a built-in Git command. Its availability and exact behavior depend on whether it's installed on your system. The default <i>base-branch-name</i> (e.g., <b>main</b> vs. <b>master</b>) might vary based on the script's specific implementation or your Git configuration. It generally assumes you have push access to the remote repository if you're not using <b>--no-push</b>.


title: AUTOMATIC BASE BRANCH UPDATE
content:
Before creating the new branch, <i>git-fresh-branch</i> often automatically fetches and pulls the latest changes for the specified or default base branch (e.g., <b>main</b>), ensuring your new branch is always up-to-date from its origin.


title: REMOTE TRACKING SETUP
content:
When pushing the new branch (unless <b>--no-push</b> is used), the command typically sets up the upstream tracking for the new branch, meaning future <b>git pull</b> or <b>git push</b> commands on that branch will work seamlessly without specifying the remote or branch name.


title: HISTORY
content:
<i>git-fresh-branch</i> (or similar utility scripts like <i>git-new-branch</i>) emerged from the Git community's desire to simplify common multi-step workflows. Developers often found themselves repeatedly performing <b>git checkout main</b>, <b>git pull</b>, <b>git checkout -b new-branch</b>, and <b>git push -u origin new-branch</b>. Scripts like this automate these repetitive steps, improving efficiency and reducing human error. Its development is generally grassroots, driven by individual developers sharing useful shortcuts.


title: SYNOPSIS
content:
<b>git fsck</b> [--full] [--unreachable] [--dangling] [--lost-found] [--no-reflogs] [--strict] [--connectivity-only] [--root] [--tags] [--cache] [--objects] [--indexed-objects] [--name-objects] [--progress] [--no-progress] [<I>object_id</I>...]


title: PARAMETERS
content:
<b>--full</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check all objects accessible from reachable refs, plus all objects in the object database. This is typically what you want for a comprehensive check.<br><br><b>--unreachable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print objects that are <i>unreachable</i> from any known branch or tag.<br><br><b>--dangling</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print objects that are <i>dangling</i> (not referenced by any other object, but still valid).<br><br><b>--lost-found</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write <i>unreachable</i> and <i>dangling</i> objects into <i>.git/lost-found/commit/</i> or <i>.git/lost-found/other/</i> respectively.<br><br><b>--no-reflogs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not consider reflogs when determining reachability.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check objects more strictly, reporting additional errors.<br><br><b>--connectivity-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only check connectivity, not validity of content.<br><br><b>--root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report root commits that are not reachable from any ref.<br><br><b>--tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report tags that do not point to a valid object.<br><br><b>--cache</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Consider objects in the index as reachable.<br><br><b>--objects</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit output to objects only, not references.<br><br><b>--indexed-objects</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only consider objects that are mentioned in the index.<br><br><b>--name-objects</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show human-readable names for objects if possible.<br><br><b>--progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show progress during the check.<br><br><b>--no-progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show progress during the check.<br><br>


title: DESCRIPTION
content:
<i>git-fsck</i> (file system check) is a Git command used to <b>verify the connectivity and validity of the objects</b> in the Git object database. It scans the repository's objects to find corrupted or unreachable objects, ensuring that the repository's internal structure is sound.<br><br>This command is crucial for maintaining the <b>health and integrity</b> of a Git repository, especially after unexpected system crashes or disk errors. It can identify dangling objects (objects not referenced by any commit or branch), unreachable objects (objects that are still valid but not reachable from any known branch or tag), and corrupted objects. <i>git-fsck</i> is a <i>read-only</i> operation; it does not modify the repository.


title: CAVEATS
content:
<i>git-fsck</i> is a <b>diagnostic tool</b> only. It reports issues but <i>does not fix them</i>. For example, it will identify corrupted objects but will not attempt to repair them. To recover objects, manual intervention or other Git commands like <i>git restore</i> (if in index) or <i>git replace</i> may be needed, often after manually inspecting objects found in <i>lost-found</i>. It's also important to note that <i>git-fsck</i> can be resource-intensive on very large repositories.


title: USE IN RECOVERY
content:
<i>git-fsck</i> is often the first step in diagnosing repository corruption or data loss. By identifying dangling or unreachable objects, it provides clues that can be used with <i>git-cat-file</i> and <i>git-reset</i> or <i>git-cherry-pick</i> to <I>potentially recover lost work</I>.


title: READ-ONLY NATURE
content:
Emphasizing its read-only nature is crucial. It gives confidence that running the command won't worsen any existing problems in the repository, making it safe to use for initial diagnosis.


title: HISTORY
content:
<i>git-fsck</i> has been a fundamental component of Git since its early days, serving as the <b>primary integrity checker</b> for the object database. Its design reflects Git's core principle of data integrity, allowing users to verify the internal consistency of their repositories. Its evolution has focused on adding more diagnostic options and improving performance rather than changing its core function.


title: SYNOPSIS
content:
git gc [--aggressive] [--auto] [--prune=<date> | --prune=now] [--force] [--quiet] [--shared] [--no-prune]


title: PARAMETERS
content:
<b>--aggressive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optimize</i> the repository more aggressively to save disk space, potentially taking longer to complete.<br><br><b>--auto</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run garbage collection only if certain internal thresholds (e.g., number of loose objects or packfiles) are exceeded. This is the default behavior when <i><code>git gc</code></i> is triggered by other commands.<br><br><b>--prune=<date></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prune unreachable objects that are older than the specified <date>. Use <i><code>--prune=now</code></i> to prune all unreachable objects immediately, regardless of age.<br><br><b>--no-prune</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prune any objects. Useful when you only want to repack without deleting.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force garbage collection to run, even if Git believes it is not necessary based on its internal checks.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all progress and completion messages, running silently.<br><br><b>--shared</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize for repositories that are shared among multiple users, ensuring that packfiles are readable by all.<br><br>


title: DESCRIPTION
content:
<i><code>git gc</code></i> performs garbage collection on your Git repository, aiming to optimize disk space usage and improve performance. It achieves this by packing loose objects into efficient packfiles and pruning unreachable objects from the object database. This command cleans up various forms of redundant data, including stale packfiles, dangling objects, and old reflogs. While it can be run manually, it is also frequently invoked automatically by other Git commands (like <i><code>git commit</code></i> or <i><code>git merge</code></i>) when certain thresholds are met, ensuring continuous repository health and efficiency.


title: CAVEATS
content:
Running <i><code>git gc --aggressive</code></i> can be time-consuming for large repositories.<br>While <i><code>--auto</code></i> helps, it doesn't guarantee a full repack if conditions aren't met, potentially leaving some loose objects.<br>Objects that are part of the repository's history (even if seemingly 'lost') are preserved unless explicitly pruned via <i><code>--prune</code></i> and are no longer reachable by any reflog or reference.


title: <B>AUTOMATIC GARBAGE COLLECTION (`--AUTO`)</B>
content:
When invoked with <i><code>--auto</code></i>, <i><code>git gc</code></i> checks if the number of loose objects or packfiles exceeds certain thresholds. These thresholds are configurable via <i><code>git config</code></i> variables such as <i><code>gc.auto</code></i> (default 6700 loose objects) and <i><code>gc.autoPackLimit</code></i> (default 50 packfiles). If either threshold is met, a full garbage collection runs. This automatic behavior prevents the repository from accumulating excessive loose objects or packfiles, maintaining optimal performance without constant manual intervention.


title: <B>OBJECT STORAGE CONCEPTS</B>
content:
Git stores objects (blobs, trees, commits, tags) either as <i>loose objects</i> or within <i>packfiles</i>. Loose objects are individual files for each object, convenient for quick writes and additions. Packfiles are compressed archives of multiple objects, highly efficient for storage and network transfer. <i><code>git gc</code></i>'s primary role is to consolidate these loose objects into packfiles and remove obsolete or unreachable objects, thereby optimizing storage and retrieval performance within the repository.


title: HISTORY
content:
<i><code>git gc</code></i> has been a fundamental command in Git since its early days, designed to maintain repository health and efficiency. As Git repositories grow in size and complexity, the importance of efficient garbage collection has led to continuous improvements in its automatic behaviors and configuration options, making it a robust maintenance tool.


title: PARAMETERS
content:
<b>tarball_path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <b>required</b> path to the <i>.tar</i> or <i>.tar.gz</i> archive file from which to extract the commit ID.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more details about the extraction process and any encountered metadata.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all standard output except for the extracted commit ID itself, useful for scripting.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If enabled, the command will attempt to validate the extracted commit ID against a local Git repository, ensuring it's a valid and reachable commit. An error will be returned if validation fails.<br><br><b>--metadata-file &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the expected path to the metadata file <i>inside</i> the tarball that contains the commit ID. Defaults typically to <i>.git_archival.txt</i> or similar patterns used by <b>git archive</b>.<br><br>


title: DESCRIPTION
content:
The <i>git-get-tar-commit-id</i> command is a specialized utility, typically a custom script, designed to extract the Git commit identifier (SHA-1 hash) embedded within a tarball. This is particularly useful for tar archives generated by <b>git archive</b>, which can include metadata like the commit hash, short hash, date, and branch information in a file such as <i>.git_archival.txt</i>. <br><br>The primary purpose of this command is to provide traceability for release artifacts. By obtaining the exact commit ID, developers and users can precisely identify the source code version from which a given tarball was created, aiding in debugging, reproduction of builds, and ensuring consistency across different deployments. It serves as a crucial link between a distributed release artifact and its specific point in the Git version history. Since it's not a standard Git subcommand, its implementation can vary, but its core function remains consistent: linking a tarball back to its original Git commit.


title: CAVEATS
content:
This command is <b>not a standard Git subcommand</b> distributed with Git itself; it is typically a custom helper script or part of a larger build system. Its functionality relies heavily on the tarball containing embedded Git metadata, usually generated by <b>git archive</b>. If the tarball was created by other means (e.g., direct <b>tar</b> command without Git context), this command will likely fail to find any commit ID. Its exact behavior and available options may vary depending on the specific implementation.


title: INTEGRATION WITH CI/CD PIPELINES
content:
<i>git-get-tar-commit-id</i> is frequently integrated into Continuous Integration and Continuous Deployment (CI/CD) workflows. It allows automated systems to verify the source of deployed artifacts, log specific commit IDs for released versions, or trigger subsequent actions based on the exact code version. For instance, a deployment script might use this command to tag a release in the Git repository with the specific commit ID found in the deployed tarball.


title: HOW GIT METADATA IS EMBEDDED
content:
When using <b>git archive</b>, Git can embed a variety of metadata into the generated tarball. By default, it often creates a file named <i>.git_archival.txt</i> at the root of the archive. This file typically contains lines like 'ref: HEAD', 'commit-id: &lt;SHA1&gt;', 'short-id: &lt;short_SHA1&gt;', 'tag: &lt;tag_name&gt;', and 'date: &lt;date&gt;'. The <i>git-get-tar-commit-id</i> command works by extracting and parsing this file to retrieve the 'commit-id' field.


title: HISTORY
content:
The need for <i>git-get-tar-commit-id</i> emerged from practical challenges in software development and release management. As Git became the dominant version control system, projects frequently needed to distribute source code or build artifacts as tarballs. To maintain transparency and reproducibility, it became essential to link these distributed packages directly back to the exact Git commit they represented. <br><br>While <b>git archive</b> could embed this information, a dedicated tool was often required to reliably extract it from the generated tarballs. This led to the creation of various ad-hoc scripts and utilities within build pipelines and CI/CD systems, collectively fulfilling the role described by <i>git-get-tar-commit-id</i>. Its development is driven by the practical requirement of ensuring clear traceability from a distributed artifact back to its precise source code version.


title: SYNOPSIS
content:
<I>git-gh-pages</I> [<B>--branch</B> <I>branch-name</I>] [<B>--message</B> <I>commit-message</I>] [<B>--force</B>] [<B>--no-clean</B>] [<I>source-directory</I>]


title: PARAMETERS
content:
<b><I>source-directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The local directory containing the static files to be published. This is typically the output of a static site generator's build process (e.g., <I>build/</I>, <I>public/</I>, or <I>dist/</I>).<br><br><b><B>--branch</B> <I>branch-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target branch to push the content to. Defaults to <I>gh-pages</I> if not specified.<br><br><b><B>--message</B> <I>commit-message</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a custom commit message for the new commit on the <I>gh-pages</I> branch. If omitted, a default message like 'Deploy GitHub Pages' is often used.<br><br><b><B>--force</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the push to the remote branch, overwriting its history. Use with extreme caution, as it can lead to irreversible data loss on the remote branch if not used carefully.<br><br><b><B>--no-clean</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the command from deleting existing files in the target branch before copying the new content. This can be useful for partial updates or maintaining specific files.<br><br>


title: DESCRIPTION
content:
The command <I>git-gh-pages</I> refers to a utility or script designed to simplify the deployment of static web content to the <I>gh-pages</I> branch of a Git repository, which is then served by GitHub Pages. It automates the process of taking a compiled static site (e.g., from a <I>build/</I> or <I>dist/</I> directory), committing it to a dedicated branch (typically <I>gh-pages</I>), and pushing it to the remote repository.<br><br>While not a standard command shipped with Git itself, various implementations exist as shell scripts, Node.js packages (like the <I>gh-pages</I> npm package), or custom build automation steps. Its primary purpose is to streamline the continuous deployment of documentation, project websites, or personal portfolios hosted on GitHub.


title: CAVEATS
content:
The exact behavior and available options of <I>git-gh-pages</I> can vary significantly, as it is not a universally standardized command; its functionality depends on the specific script or tool implementation being used. Implementations often require the <I>gh-pages</I> branch to be an 'orphan' branch (i.e., having no common history with the project's main development branch). Using the <B>--force</B> option should be done with great care due to the risk of data loss.


title: TYPICAL WORKFLOW
content:
A common workflow involves:<br>1. Building your static site (e.g., <I>npm run build</I>, which outputs to <I>dist/</I>).<br>2. Running <I>git-gh-pages</I> with the build output directory (e.g., <I>git-gh-pages dist/</I>).<br>This process typically involves these underlying steps:<br> <B>a.</B> Switching to the <I>gh-pages</I> branch (or creating it if it doesn't exist and making it an orphan branch).<br> <B>b.</B> Copying the contents of the <I>source-directory</I> to the root of the <I>gh-pages</I> branch, often after clearing existing contents.<br> <B>c.</B> Staging and committing these new changes.<br> <B>d.</B> Pushing the <I>gh-pages</I> branch to the remote repository (e.g., <I>origin gh-pages</I>).<br> <B>e.</B> Switching back to the original development branch (e.g., <I>main</I>).


title: HISTORY
content:
The concept of <I>git-gh-pages</I> emerged with the popularity of GitHub Pages, a feature introduced by GitHub to host static websites directly from a repository's <I>gh-pages</I> branch. As static site generators (like Jekyll, Hugo, Eleventy) and client-side web development grew, automating the deployment process became crucial. Early users often relied on manual Git commands or custom shell scripts. Over time, community-driven tools and npm packages (e.g., <I>gh-pages</I>) were developed to encapsulate this common workflow, making it easier for developers to publish their sites without complex CI/CD setups.


title: SYNOPSIS
content:
<i>Note: <b>git-graft</b> is not a standalone command. This section describes the format of the deprecated <b>.git/info/grafts</b> file, which implemented the grafting functionality.</i><br><br><b><I>.git/info/grafts</I></b><br><br>Each line in this file specifies a graft, formatted as:<br><b><I>commit_id parent_id ...</I></b>


title: PARAMETERS
content:
<b><i>commit_id</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The 40-character SHA-1 hash of the commit whose parents are to be overridden by the graft.<br><br><b><i>parent_id ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more 40-character SHA-1 hashes representing the new parent(s) for the specified <i>commit_id</i>. If multiple parents are provided, the commit is treated as a merge commit with these new parents. If no <i>parent_id</i> is given, the commit becomes a root commit.<br><br>


title: DESCRIPTION
content:
The term <b>git-graft</b> refers to a historical and now deprecated mechanism in Git for locally altering the parent pointers of existing commits without actually rewriting their SHA-1 hashes. This functionality was primarily managed through the <b>.git/info/grafts</b> file within a repository. By adding lines to this file, users could effectively "graft" a commit onto a different parent in the commit graph, making it appear as if that commit had a different history in the local repository. This was useful for tasks such as connecting disconnected histories, fixing broken merges, or temporarily visualizing an alternative commit lineage. <br><br>Unlike powerful history rewriting tools like <b>git filter-branch</b> or <b>git filter-repo</b>, which permanently alter commit objects and their hashes, grafting only provided a superficial, local view change. This made it unsuitable for pushing such changes to shared repositories. Due to its limitations and the introduction of more robust and flexible alternatives, particularly <b>git replace</b>, the <b>.git/info/grafts</b> file and the "graft" concept it represented were deprecated in Git versions 1.6.5 and later.


title: CAVEATS
content:
<b>git-graft</b> (and the underlying <b>.git/info/grafts</b> mechanism) comes with significant caveats:<br><b>Deprecated:</b> The <b>.git/info/grafts</b> file was deprecated in Git v1.6.5 and is no longer recommended for use. Modern Git versions might not fully support or might ignore it.<br><b>Local-Only Effect:</b> Grafts only affect the local repository where the <b>.git/info/grafts</b> file resides. They are not part of the repository's permanent history and cannot be pushed or pulled to other repositories.<br><b>No History Rewrite:</b> Unlike tools that rewrite history (e.g., <b>git filter-branch</b>), grafting does not change the actual commit objects or their SHA-1 hashes. It merely instructs Git to locally consider a commit as having different parents.<br><b>Superseded:</b> The functionality provided by grafting has been largely superseded by <b>git replace</b> for similar temporary, local history modifications, and by history rewriting tools for permanent changes.


title: LIMITATIONS
content:
Beyond its deprecated status and local-only nature, the <b>.git/info/grafts</b> mechanism had other limitations. It could become difficult to manage in complex scenarios and provided no inherent way to remove a graft other than manually editing the file. Furthermore, the changes were purely symbolic; Git commands like <b>git log</b> would respect the grafts, but fundamental operations that traverse actual commit objects (e.g., when cloning a shallow repository or certain types of <b>git fsck</b> checks) might behave unexpectedly or ignore the grafts, as the underlying commit objects remained unchanged.


title: HISTORY
content:
The concept of "grafting" in Git originated with the <b>.git/info/grafts</b> file, providing an early and simple mechanism for users to manipulate the perceived parentage of commits locally. This file was introduced to address scenarios where repository history needed adjustment without the complexity and performance overhead of a full history rewrite. However, its significant limitation was the local-only nature of the changes, preventing their propagation to other repositories.<br><br>As Git evolved, the need for more robust and shareable history manipulation became apparent. This led to the development of tools like <b>git filter-branch</b>, capable of truly rewriting history by creating new commit objects. For the specific use case of locally "faking" history, the more flexible and programmatic <b>git replace</b> command was introduced, providing a superior alternative to the manual <b>.git/info/grafts</b> file. Consequently, the <b>.git/info/grafts</b> mechanism was officially deprecated in Git v1.6.5, encouraging users to adopt <b>git replace</b> for similar local effects or dedicated history rewriting tools for permanent changes.


title: SYNOPSIS
content:
<b>git grep</b> [<I>options</I>] (-e <I>pattern</I> | -f <I>file</I>) ... [<I>tree-ish</I>...] [--] [<I>pathspec</I>...]


title: PARAMETERS
content:
<b>-i, --ignore-case</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores case differences when matching patterns.<br><br><b>-w, --word-regexp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches only whole words; the pattern must match only a sequence of "word" characters.<br><br><b>-v, --invert-match</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects non-matching lines.<br><br><b>-n, --line-number</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows line numbers of matching lines.<br><br><b>-c, --count</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses normal output; instead, prints a count of matching lines for each input file.<br><br><b>-l, --files-with-matches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses normal output; instead, prints the name of each input file from which output would normally have been printed.<br><br><b>-L, --files-without-matches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses normal output; instead, prints the name of each input file from which no output would normally have been printed.<br><br><b>-p, --show-function</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the function name that the matching line is part of, if applicable.<br><br><b>-A <num>, --after-context=<num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints <num> lines of trailing context after matching lines.<br><br><b>-B <num>, --before-context=<num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints <num> lines of leading context before matching lines.<br><br><b>-C <num>, --context=<num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints <num> lines of context (before and after) around matching lines.<br><br><b>-e <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a pattern. Useful when pattern starts with '-', or to use multiple patterns.<br><br><b>-f <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads patterns from <file>, one per line.<br><br><b>--and, --or, --not</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Combines multiple patterns using boolean logic (AND, OR, NOT).<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all output. Exits with status 0 if any match is found, 1 otherwise.<br><br><b>--all-match</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For patterns combined with --and, requires all patterns to match in the same line.<br><br><b>--untracked</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches files in the working tree that are not tracked by Git.<br><br><b>--no-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches files in the working tree that are not part of a Git repository or not in the index.<br><br><b>--cached</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches files in the Git index (staging area).<br><br><b>--recurse-submodules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurses into submodules when searching.<br><br><b>--no-exclude-standard</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not skip files matching standard ignore rules (e.g., in .gitignore).<br><br><b>-j <jobs>, --threads=<jobs></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of search threads to use. Defaults to number of CPU cores.<br><br><b>--format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format using printf-like placeholders.<br><br><b><tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the tree(s) to search (e.g., 'HEAD', 'v2.0', 'origin/main'). If omitted, searches the working tree and index.<br><br><b><pathspec></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the search to specific files or directories within the repository.<br><br>


title: DESCRIPTION
content:
<i>git-grep</i> is a powerful and efficient utility built into Git for searching content within files tracked by Git. Unlike standard <i>grep(1)</i>, <i>git-grep</i> is Git-aware, allowing it to search not only the current working directory but also the Git index, specific commits, and trees. It automatically ignores files specified in <i>.gitignore</i> and <i>git-exclude</i> files by default, which can be overridden.<br><br>It offers superior performance for large repositories due to its ability to utilize Git's object database and optimized indexing. It can search for patterns in text and binary files, providing flexible output options like showing line numbers, filenames, and context. Its primary advantage lies in its speed and its capability to search historical versions of files without needing to check them out.


title: CAVEATS
content:
By default, <i>git-grep</i> treats binary files specially, reporting them as matches if the pattern is found, but without displaying content. This behavior can be controlled with options like <i>--text</i>. When searching untracked files or files not in the index using <i>--untracked</i> or <i>--no-index</i>, <i>git-grep</i> might perform slower as it cannot leverage Git's optimized object database for those files.


title: PATTERNS
content:
<i>git-grep</i> uses POSIX Extended Regular Expressions by default. Options like <i>--fixed-strings</i> (or <i>-F</i>) can be used to treat the pattern literally, and <i>--basic-regexp</i> (or <i>-G</i>) for basic regular expressions, similar to standard <i>grep</i>.


title: EXIT STATUS
content:
The command exits with status 0 if matches are found, 1 if no matches are found, and a value greater than 1 for errors. This makes <i>git-grep</i> highly suitable for use in shell scripts and automated workflows.


title: HISTORY
content:
<i>git-grep</i> has been a fundamental command within the Git suite since its early days, designed to offer a Git-native search capability. Its development has consistently focused on performance, allowing it to efficiently search across large codebases and historical versions of files. It leverages Git's internal data structures and object model, making it significantly faster and more powerful for Git repositories than traditional filesystem-level <i>grep</i> operations, especially when searching across commits or the index.


title: PARAMETERS
content:
<b><b>--amend</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When opening the commit tool (citool), automatically configure it to amend the previous commit. This allows modifying the last commit's message or content.<br><br><b><b>--rebase</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When opening the commit tool, configure it to perform an interactive rebase, allowing you to select and reorder commits.<br><br><b><b>--detach</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detach the <b>git-gui</b> process from the invoking terminal, allowing the terminal to be closed without terminating the GUI application.<br><br><b><b>blame &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a blame viewer for the specified file, showing who last modified each line of code.<br><br><b><b>browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a repository browser, allowing exploration of branches, tags, and commits.<br><br><b><b>citool</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly open the commit tool, which is the default view when <b>git gui</b> is invoked without a command.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the status view, displaying current staged and unstaged changes, similar to the default view.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for <b>git-gui</b>.<br><br>


title: DESCRIPTION
content:
The <b>git-gui</b> command provides a lightweight, Tcl/Tk-based graphical user interface for interacting with Git repositories. It simplifies common Git operations such as staging changes, committing, browsing history, and managing branches. Designed for ease of use, it allows users to visually inspect changes, perform commits, amend previous commits, and handle basic repository maintenance without needing to use the command line for every action. While not as feature-rich as some modern IDE integrations or commercial Git clients, <b>git-gui</b> is part of the official Git distribution and offers a robust set of functionalities for everyday Git tasks, making it an excellent tool for users who prefer a visual workflow.<br><br>It's particularly useful for new Git users or those who want a quick visual overview of their repository's status.


title: CAVEATS
content:
<b>git-gui</b> relies on Tcl/Tk, which might need to be installed separately on some minimal Linux distributions.<br>While user-friendly, it may not offer the full depth of control or advanced features available via the command-line Git or more comprehensive graphical clients.<br>Its interface, being Tcl/Tk-based, might appear less modern than native GUI applications on some desktop environments.


title: CONFIGURATION
content:
<b>git-gui</b> respects various Git configuration variables set using <b>git config</b>, such as `gui.encoding` for character encoding and `gui.recentrepo` for managing recently opened repositories. These settings can be configured globally or per-repository to customize the GUI's behavior and appearance.


title: HISTORY
content:
<b>git-gui</b> was developed by Shawn O. Pearce and is a standard part of the official Git distribution. It was designed to provide a simple, cross-platform graphical interface for common Git operations, making Git more accessible to a broader range of users, particularly those who prefer visual tools over the command line. Its inclusion in the core Git project has made it a de facto basic GUI for Git on many systems.


title: PARAMETERS
content:
<b>commit1</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. The older commit hash or reference. If omitted, defaults to the parent of <i>commit2</i> (or <i>HEAD~1</i> if only one commit is provided).<br><br><b>commit2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. The newer commit hash or reference. If omitted, defaults to <i>HEAD</i>.<br><br><b>path...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. Limit the analysis to specified files or directories.<br><br><b>-s, --since <date></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show commits more recent than a specific date. <i>Date formats can be absolute (e.g., "2023-01-01"), relative (e.g., "2 weeks ago"), or a timestamp.</i><br><br><b>-e, --until <date></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show commits older than a specific date. <i>Useful for defining the end of a time window.</i><br><br><b>--no-merges</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not follow merged commits. <i>This excludes changes introduced directly by merge commits.</i><br><br><b>--porcelain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce machine-readable output. <i>The output format becomes more structured, typically one author per line with counts.</i><br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all changes, including renames and copies. <i>By default, git-guilt might simplify certain diffs; this ensures a comprehensive view.</i><br><br><b>--no-renames</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable rename detection. <i>Treats renamed files as deletions and additions rather than just renames.</i><br><br><b>--full-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show full index info for diff. <i>Includes full object names on the command line output, useful for debugging or detailed analysis.</i><br><br>


title: DESCRIPTION
content:
<i>git-guilt</i> is a utility from the <i>git-extras</i> collection designed to analyze code churn by attributing changes between two specified points in Git history to individual authors. Unlike <i>git blame</i> which shows who last modified each line in the <b>current</b> version of a file, <i>git-guilt</i> identifies who <b>caused</b> the changes (additions, deletions, modifications) to lines that are different between an older commit and a newer one. It aggregates these changes by author, providing insights into who has been most active or responsible for the evolution of a codebase or specific files within a given range of commits. This command is particularly useful for understanding the impact of developers over a period, tracking feature development, or analyzing refactoring efforts. It helps to answer "who is responsible for the difference between this version and that version?"


title: CAVEATS
content:
<b>External Dependency:</b> <i>git-guilt</i> is not a core Git command. It is part of <i>git-extras</i>, a collection of supplementary Git utilities. Users must install <i>git-extras</i> separately to use <i>git-guilt</i>.<br><br><b>Performance:</b> Analyzing a large range of commits or an entire repository with extensive history can be computationally intensive and may take a significant amount of time.<br><br><b>Interpretation:</b> While it attributes changes to authors, it's essential to understand that "guilt" in this context refers to authorship of changes, not necessarily negative responsibility. It's a measure of active contribution to code evolution.


title: <B><I>UNDERSTANDING "GUILT"</I></B>
content:
The term "guilt" in <i>git-guilt</i> should be understood as "responsibility for changes" rather than a negative connotation. It quantifies an author's contribution to the delta between two commits, making it valuable for code ownership analysis, understanding developer activity, or pinpointing who introduced specific changes.


title: <B><I>TYPICAL USE CASES</I></B>
content:
<b>Feature Analysis:</b> Determine which developers contributed most to a new feature branch.<br><b>Refactoring Impact:</b> Identify who was most involved in a large refactoring effort.<br><b>Onboarding:</b> Understand which parts of the codebase new team members are actively modifying.<br><b>Code Evolution:</b> Analyze how contributions change over time in a specific module.


title: HISTORY
content:
<i>git-guilt</i> is a relatively specialized command that gained popularity as part of the <i>git-extras</i> project, which began development around 2009-2010. <i>git-extras</i> aims to provide various convenient Git workflows and analyses that are not natively included in the core Git distribution. <i>git-guilt</i> fills a niche for analyzing authorship of code churn, a task not directly addressed by core commands like <i>git blame</i> or <i>git log</i>. Its ongoing development is tied to the <i>git-extras</i> project, which is maintained by its community.


title: SEE ALSO
content:
<i>git log(1)</i>: Shows commit logs. Can be used to view history before running <i>git-guilt</i>., <i>git blame(1)</i>: Shows what revision and author last modified each line of a file. Unlike <i>git-guilt</i>, it operates on the current state of a file, not changes between two states., <i>git diff(1)</i>: Shows changes between commits, commit and working tree, etc. <i>git-guilt</i> uses diffing internally., <i>git shortlog(1)</i>: Summarizes <i>git log</i> output, grouping commits by author.


title: SYNOPSIS
content:
<code>git hash-object [<b>-w</b>] [<b>--stdin</b> | <b>--stdin-paths</b>] [<b>--literally</b>] [<b>-t</b> &lt;type&gt;] [<b>--path</b>=&lt;path&gt;] [<b>--no-filters</b>] [<b>--no-replace-object</b>] &lt;file&gt;...</code>


title: PARAMETERS
content:
<b><b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Write the object into the object database. Without this option, the command only outputs the hash to standard output.</I><br><br><b><b>--stdin</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Read the object's content from standard input instead of from a file specified on the command line.</I><br><br><b><b>--stdin-paths</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Read null-terminated paths from standard input, and compute and optionally write the hash of each file found at those paths. This is typically used with <code>git add --hash</code>.</I><br><br><b><b>--literally</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>When <code><b>--stdin</b></code> is used, treat the input as literal content to be hashed, not a path to a file whose content should be hashed. This is the default behavior when <code><b>--stdin</b></code> is used without <code><b>--path</b></code>.</I><br><br><b><b>-t &lt;type&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify the type of object. Valid types are <b>blob</b> (default), <b>tree</b>, <b>commit</b>, and <b>tag</b>.</I><br><br><b><b>--path=&lt;path&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Hash the content as if it were a file at the specified <i>&lt;path&gt;</i>. This is important for applying content filters (e.g., CRLF conversion or custom clean/smudge filters) defined in <code>.gitattributes</code> for the given path.</I><br><br><b><b>--no-filters</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not apply content filters (e.g., CRLF conversion, clean/smudge filters) even if <code><b>--path</b></code> is specified. The content is hashed exactly as-is.</I><br><br><b><b>--no-replace-object</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Don't replace existing objects in the database, even if an object with the same hash already exists. This can prevent unexpected behavior in certain workflows.</I><br><br><b><b>&lt;file&gt;...</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>One or more file paths whose content should be hashed. This is ignored if <code><b>--stdin</b></code> or <code><b>--stdin-paths</b></code> is used.</I><br><br>


title: DESCRIPTION
content:
<I><code>git hash-object</code> is a low-level "plumbing" command used to compute the SHA-1 (or configured hash) of a file or content, and optionally write that object to the Git object database. It takes content from a file path or standard input. This command is fundamental for understanding how Git stores objects and is often used in scripts or for manual object manipulation rather than day-to-day operations. It allows specifying the object type (blob, tree, commit, tag) and handles content filtering based on <code>.gitattributes</code>.</I>


title: CAVEATS
content:
<I>This is a "plumbing" command, meaning it's designed for scripting and internal Git operations rather than direct user interaction. Misuse can lead to a corrupted repository or unexpected behavior, especially when writing objects without fully understanding Git's internal object model.</I><br><I>When using <code><b>--stdin</b></code>, ensure the input stream is correctly terminated or closed, especially for binary data, to avoid premature hashing or waiting for more input.</I>


title: OBJECT TYPES IN GIT
content:
<I>Git stores different types of objects: <b>blobs</b> (file contents), <b>trees</b> (directory structures representing snapshots), <b>commits</b> (snapshots of the repository at a specific point in time, linking to trees and parents), and <b>tags</b> (references to specific commits or objects, often used for releases). <code><b>git hash-object</b></code> primarily deals with blobs by default but can simulate other types using the <code><b>-t</b></code> option for specific use cases.</I>


title: PLUMBING VS. PORCELAIN COMMANDS
content:
<I><code><b>git hash-object</b></code> is considered a 'plumbing' command. Git commands are broadly categorized into 'porcelain' (user-friendly, high-level commands like <code><b>git commit</b></code>, <code><b>git branch</b></code>) and 'plumbing' (low-level, internal commands like <code><b>git hash-object</b></code>, <code><b>git cat-file</b></code>). Plumbing commands are the fundamental building blocks upon which the more convenient porcelain commands are constructed, making them crucial for understanding Git's internals and for advanced scripting.</I>


title: HISTORY
content:
<I>The <code>git hash-object</code> command has been a core part of Git since its early days, serving as one of the fundamental "plumbing" commands that operate directly on the object database. It was essential for Linus Torvalds' initial design, allowing Git to store and address content by its hash. Its existence highlights Git's content-addressable storage model, where data integrity is inherently linked to content hashing. It has remained relatively stable over time, reflecting its foundational role.</I>


title: SYNOPSIS
content:
<i>git</i> help [--web] [--man] [--info] [--external] [--verbose] [--aliases] [--config] <command>|<guide><br><i>git</i> help [-g|--guides]<br><i>git</i> help [-a|--all]


title: PARAMETERS
content:
<b><b>--web</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the help documentation in a web browser. The specific browser used is determined by Git's configuration.<br><br><b><b>--man</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help in the manual page format (this is the default behavior). Uses the system's `man` viewer.<br><br><b><b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help in the GNU info format. This requires an `info` viewer to be installed and configured.<br><br><b><b>--external</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Look for external help commands or documentation. This is useful for third-party Git tools or scripts.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more detailed information, especially when listing aliases, showing their full command definitions.<br><br><b><b>--aliases</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all configured Git aliases and their corresponding command definitions, similar to `git config --get-regexp alias`.<br><br><b><b>--config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all configured Git variables, similar to `git config --list`. Provides a quick overview of the current Git setup.<br><br><b><b>&lt;command&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of a Git command (e.g., `clone`, `status`, `commit`) for which to display the manual page.<br><br><b><b>&lt;guide&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of a Git conceptual guide (e.g., `revisions`, `everyday`, `tutorial`) for which to display the documentation.<br><br><b><b>-g</b>, <b>--guides</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available Git conceptual guides. This provides an overview of the various topics covered in Git's documentation.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available Git commands and conceptual guides. This is a comprehensive list of all documentation accessible via `git help`.<br><br><b><b>--no-strict-enum-validation</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An internal option primarily used for development and testing; generally not intended for direct user interaction.<br><br>


title: DESCRIPTION
content:
The `git-help` command is the underlying mechanism that powers the `git help` interface, providing comprehensive access to Git's extensive documentation system. It serves as the primary gateway for users to understand Git commands, conceptual guides, and various aspects of the Git version control system. By default, it displays information via `man` pages, offering a terminal-based, paginated view. However, it also supports displaying documentation in a web browser for a more interactive experience or as GNU `info` pages. Users can query specific command manuals like `git help clone`, delve into conceptual guides such as `git help everyday`, or list all available commands and guides. This command is crucial for learning and referencing Git's extensive functionalities, making it an indispensable tool for both beginners and experienced users navigating the complexities of Git.


title: CAVEATS
content:
The specific viewer used for displaying documentation (e.g., `less` for `man` pages, a web browser for `--web`) is determined by system environment variables (like `PAGER`, `BROWSER`, `MANPAGER`, `INFOPAGER`) and Git's internal configuration (`help.format`, `help.browser`, `man.viewer`, `info.viewer`). Ensuring these are correctly set is important for the desired display behavior. Web help requires a compatible web browser to be installed and accessible to the system.


title: CONFIGURATION
content:
The behavior of `git help` can be extensively customized through Git's configuration system. Variables like <b>help.format</b> (e.g., `man`, `web`, `info`), <b>help.browser</b>, <b>man.viewer</b>, and <b>info.viewer</b> allow users to define their preferred methods and tools for displaying documentation. These settings provide flexibility to adapt the help system to individual workflows and environments.


title: EXTENSIBILITY
content:
Git's help system is designed to be extensible. Users can integrate documentation for their own custom Git commands or scripts by configuring Git's `man-pages.path` or `info.path` variables. This allows external tools to seamlessly become part of the `git help` framework, providing a unified documentation experience for all Git-related functionalities.


title: HISTORY
content:
The `git help` command (and its underlying `git-help` executable) has been a fundamental component of Git since its early iterations, designed to provide an integrated and consistent means of accessing documentation. Its evolution has focused on enhancing the accessibility and presentation of information, progressively adding options like `--web` for browser-based viewing and improving its ability to list all commands and conceptual guides. This continuous development reflects Git's commitment to being a self-documenting system, ensuring that users can always find necessary information directly from the command line interface.


title: SYNOPSIS
content:
Typically invoked by a web server as a CGI or FastCGI script, not directly by a user. The common invocation pattern from a web server's perspective looks like this:<br><br><b><pre>  git-http-backend</pre></b><br>Its behavior is primarily controlled by environment variables set by the web server and Git configuration settings within the repository or system.


title: PARAMETERS
content:
<b>GIT_PROJECT_ROOT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the base directory from which Git repositories are served. The path requested by the client is interpreted relative to this root. This environment variable <b>must</b> be set for <i>git-http-backend</i> to function correctly.<br><br><b>GIT_HTTP_EXPORT_ALL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set to "true" or "1", all Git repositories under <i>GIT_PROJECT_ROOT</i> are made available for fetching, even if they don't contain a <i>git-daemon-export-ok</i> file. This setting overrides the per-repository export control.<br><br><b>GIT_HTTP_MAX_REQUEST_BUFFER</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the maximum size in bytes of the request body that <i>git-http-backend</i> will read from the web server. This helps prevent very large or malicious requests from consuming excessive memory.<br><br><b>GIT_DIR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Usually set automatically by the web server based on the URL path to point to the specific Git repository being accessed (e.g., <i>/path/to/repo.git</i>).<br><br><b>REMOTE_USER</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set by the web server after successful authentication. <i>git-http-backend</i> can use this variable for authorization checks if configured, but typically it's the web server's responsibility to handle access control.<br><br><b>GIT_HTTP_LOW_SPEED_LIMIT / GIT_HTTP_LOW_SPEED_TIME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <i>curl</i>'s options, these detect too-slow clients or connections. If the transfer speed drops below <i>GIT_HTTP_LOW_SPEED_LIMIT</i> bytes per second for <i>GIT_HTTP_LOW_SPEED_TIME</i> seconds, the connection is aborted. Useful for mitigating denial-of-service attacks.<br><br><b>GIT_HTTP_UPLOAD_PACK_REQUEST_DEFLATE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set to "1", enables deflate compression for the request body of the <i>git-upload-pack</i> protocol.<br><br><b>GIT_HTTP_RECEIVE_PACK_REQUEST_DEFLATE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set to "1", enables deflate compression for the request body of the <i>git-receive-pack</i> protocol (push operations).<br><br>


title: DESCRIPTION
content:
<i>git-http-backend</i> is a server-side program that acts as a Common Gateway Interface (CGI) or FastCGI application to serve Git repositories over HTTP and HTTPS protocols. It is typically invoked by a web server (such as Apache or Nginx) configured to execute CGI scripts. Unlike <i>git-daemon</i>, which operates on its own dedicated port, <i>git-http-backend</i> leverages the web server's existing infrastructure, including its authentication, authorization, logging, and SSL/TLS capabilities.<br><br>When a client initiates a Git operation (like <i>git clone</i>, <i>git pull</i>, or <i>git push</i>) over HTTP/S, the web server receives the request and executes <i>git-http-backend</i>. This backend then processes the request, communicates with the Git repository, and sends the appropriate Git protocol responses back to the client via the web server. It supports both "smart" HTTP protocol (efficient pack transfers using <i>git-upload-pack</i> and <i>git-receive-pack</i>) and "dumb" HTTP protocol (simpler file serving for older clients or basic browsing).<br><br>It's crucial for <i>git-http-backend</i> to be configured correctly with environment variables, particularly <i>GIT_PROJECT_ROOT</i>, to locate repositories. Pushing functionality is enabled by default in modern Git versions, but can be controlled with the <i>http.receivepack</i> configuration setting.


title: CAVEATS
content:
<b>1. Direct Invocation:</b> <i>git-http-backend</i> is not intended for direct execution by end-users. It relies on a web server (like Apache, Nginx, or Lighttpd) to handle HTTP requests, set up the environment, and pass data via CGI or FastCGI.<br><br><b>2. Web Server Configuration:</b> Proper functionality heavily depends on correct web server configuration, including mapping URLs to the script, setting necessary environment variables (<i>GIT_PROJECT_ROOT</i> being critical), and configuring authentication and authorization rules.<br><br><b>3. Security:</b> While <i>git-http-backend</i> handles the Git protocol, security (authentication, authorization) is primarily the responsibility of the surrounding web server infrastructure. Misconfigurations can expose repositories.<br><br><b>4. Performance:</b> As a CGI application, each request might spawn a new process, potentially impacting performance for high-traffic servers. FastCGI or more advanced setups can mitigate this.<br><br><b>5. Push Support:</b> Pushing over HTTP/S requires the <i>http.receivepack</i> Git configuration option to be enabled (it's often true by default in recent Git versions). The web server must also allow POST requests to the script.


title: REPOSITORY EXPORT CONTROL
content:
By default, <i>git-http-backend</i> only serves repositories that contain a special file named <i>git-daemon-export-ok</i> in their root directory. This acts as an explicit opt-in mechanism for public access. Alternatively, setting the <i>GIT_HTTP_EXPORT_ALL</i> environment variable to "true" or "1" will override this behavior and make all repositories under <i>GIT_PROJECT_ROOT</i> available for fetching.


title: ENABLING GIT PUSH OVER HTTP
content:
For clients to be able to push (write) to a repository over HTTP/S, two conditions must be met:<br>1. The web server must be configured to allow POST requests to the <i>git-http-backend</i> script.<br>2. The repository being pushed to must have the Git configuration variable <i>http.receivepack</i> set to <i>true</i>. This can be done using `git config http.receivepack true` inside the repository. This setting is often true by default in newer Git versions, but it's important to verify.


title: HISTORY
content:
The <i>git-http-backend</i> was introduced early in Git's development as a flexible way to serve repositories over standard HTTP/S protocols, leveraging existing web server infrastructure. This allowed for easier integration with corporate networks, firewalls, and existing authentication mechanisms, contrasting with the custom Git protocol served by <i>git-daemon</i>. Its evolution has focused on robustness, performance improvements, and adapting to modern Git protocol features, solidifying its role as a primary method for serving Git repositories, especially in enterprise environments.


title: PARAMETERS
content:
<b>-a | --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch all references from the remote repository.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a checkout operation after fetching. (Less common in modern usage, typically handled by higher-level commands.)<br><br><b>-t | --tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch all tags from the remote repository.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update existing references. (Similar to -c in context of older usage.)<br><br><b>--mirror</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mirror the remote repository, fetching all branches and tags, and pruning obsolete local refs.<br><br><b>&lt;url&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the remote Git repository to fetch from.<br><br><b>&lt;refspec&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional list of refspecs to fetch. A refspec specifies which refs on the remote are mapped to which local refs.<br><br>


title: DESCRIPTION
content:
<i>git-http-fetch</i> is a <br><b>plumbing command</b><br> in Git, primarily used internally by higher-level commands like <br><i>git fetch</i><br> or <br><i>git pull</i><br> when interacting with Git repositories over HTTP or HTTPS. It implements the "dumb" HTTP protocol, which involves fetching individual Git objects (commits, trees, blobs) and reference advertisements directly from a web server. Unlike the more efficient "smart" HTTP protocol (handled by <br><i>git-remote-http</i><br>), the dumb protocol requires more HTTP requests and can be less performant for large repositories or frequent updates. It is typically not invoked directly by users, but rather orchestrates the low-level data transfer for Git's HTTP client.


title: CAVEATS
content:
This command implements the "dumb" HTTP protocol, which is less efficient than the "smart" HTTP protocol used by <br><i>git-remote-http</i><br>. It is primarily an internal plumbing command and is generally not intended for direct user invocation. Its functionality has largely been superseded or integrated into <br><i>git-remote-http</i><br> for modern Git versions, which handle both smart and dumb HTTP transport. Authentication for HTTP/S remotes might require external credential helpers.


title: HISTORY
content:
<i>git-http-fetch</i><br> was one of the earliest components enabling Git to interact with repositories over HTTP/HTTPS. It was crucial for allowing Git users to clone and pull from servers without direct SSH access or the specialized Git protocol. Over time, the more efficient "smart" HTTP protocol was developed, and its implementation, <br><i>git-remote-http</i><br>, largely absorbed and improved upon the capabilities of <br><i>git-http-fetch</i><br>, relegating the latter to a more specialized or fallback role for older, "dumb" HTTP servers or as a low-level internal component.


title: SYNOPSIS
content:
<b>git http-push</b> [--all | --branches | --tags] [--dry-run] [--force] [--keep] [--thin] [--verbose] [<url> <ref>...]<br><b>git http-push</b> <url> <head> <ref>...


title: PARAMETERS
content:
<b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pushes all local branches to the remote repository. Functionally similar to <b>--branches</b>.<br><br><b>--branches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pushes all local branches to the remote repository.<br><br><b>--tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pushes all local tags to the remote repository.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a 'dry run' operation, showing what would be pushed without actually performing the push. No data is actually transmitted or updated on the remote.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the update, even if it results in a non-fast-forward merge. Use with caution as this can overwrite history on the remote.<br><br><b>--keep</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps the pack file created on the server after the push operation. This is primarily for debugging or specific server-side scenarios and not typically used by end-users.<br><br><b>--thin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a 'thin pack' format during the push. This excludes objects that are already known to exist on the remote repository, potentially reducing the amount of data transferred.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the pushing process, including progress and network activity.<br><br><b><url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the remote HTTP or HTTPS Git repository to which the local changes will be pushed. For example, <i>http://example.com/repo.git</i>.<br><br><b><ref>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more local references (e.g., branch names, tag names, or SHA1 commit IDs) to push to the remote repository. For example, <i>master</i> or <i>my-feature-branch</i>.<br><br><b><head></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Specific usage) In an older, less common usage of <b>git-http-push</b>, this parameter represents the current HEAD of the remote repository, typically <i>refs/heads/master</i>.<br><br>


title: DESCRIPTION
content:
<i>git-http-push</i> is a historical Git command primarily used for pushing local branches and their associated commits to a remote Git repository served over HTTP or HTTPS protocols. It was developed to provide an alternative to SSH or the native Git protocol, especially useful in environments where only HTTP/S outbound connections were permitted.<br><br><b>Important Note:</b> This command is no longer actively maintained. Its functionality has been largely absorbed into the standard <b>git push</b> command. Users are strongly encouraged to use <b>git push</b> directly, even when dealing with HTTP/S remotes, as it provides a more robust, feature-rich, and actively maintained experience.


title: CAVEATS
content:
The <b>git-http-push</b> command is considered obsolete and is no longer actively maintained. Its functionality has been fully integrated into <b>git push</b>, which is the recommended command for all remote operations, including those over HTTP/S.<br><br>Direct invocation of <b>git-http-push</b> may lead to unexpected behavior or be incompatible with newer Git versions or server configurations. Users should always use <b>git push</b>.


title: SERVER REQUIREMENTS
content:
For <b>git-http-push</b> (and subsequently <b>git push</b> over HTTP/S) to function correctly, the remote HTTP/S server must be configured to support Git's 'smart HTTP' protocol. This typically involves the server running a Git HTTP backend application, such as <b>git-http-backend</b>, which processes Git protocol requests served via a web server like Apache or Nginx.


title: HISTORY
content:
<b>git-http-push</b> was among the initial tools developed to facilitate Git repository interaction over standard web protocols (HTTP/S), offering an alternative when SSH or the dedicated Git protocol were not viable. It addressed early needs for pushing code in environments with restrictive firewall policies.<br><br>However, as Git matured, the core <b>git push</b> command evolved to natively support HTTP/S remotes. This made <b>git-http-push</b> largely redundant. Consequently, development ceased on <b>git-http-push</b>, and Git's official documentation now explicitly directs users to rely on the more comprehensive and actively developed <b>git push</b> command for all remote operations.


title: SYNOPSIS
content:
<i>git-ignore-io</i> <b>&lt;templates...&gt;</b><br><i>git-ignore-io</i> <b>-l</b> | <b>--list</b><br><i>git-ignore-io</i> <b>-s</b> | <b>--search</b> <b>&lt;query&gt;</b><br><i>git-ignore-io</i> <b>-a</b> | <b>--append</b> <b>&lt;templates...&gt;</b>


title: PARAMETERS
content:
<b><b>&lt;templates...&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more template names (e.g., <i>linux,macos,windows,java,python</i>) to generate a `.gitignore` file for. Multiple templates should be comma-separated or space-separated depending on the specific `git-ignore-io` implementation. The output is typically printed to standard output.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available `.gitignore` templates supported by the gitignore.io service. This is useful for discovering what templates are available.<br><br><b><b>-s</b>, <b>--search</b> <b>&lt;query&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for templates that match the provided <i>query</i> string. This helps in finding specific templates without having to list all of them.<br><br><b><b>-a</b>, <b>--append</b> <b>&lt;templates...&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates the `.gitignore` content for the specified templates and appends it to an existing <i>.gitignore</i> file in the current directory. If the file does not exist, it may create it.<br><br>


title: DESCRIPTION
content:
The <i>git-ignore-io</i> command is a convenient command-line interface for the popular <a href="https://www.toptal.com/developers/gitignore/" target="_blank">gitignore.io</a> web service. It allows developers to quickly fetch and generate `.gitignore` files tailored to specific operating systems, programming languages, IDEs, and other development environments. Instead of manually creating or searching for boilerplate `.gitignore` content, this command automates the process by querying the extensive template library hosted on gitignore.io.<br><br>This utility streamlines the initial setup of Git repositories by ensuring that common project-specific files (like build artifacts, temporary files, and OS-generated metadata) are correctly ignored from version control, leading to cleaner repositories and preventing accidental commits of irrelevant data. It typically acts as a wrapper around HTTP requests (often using `curl`) to the web service's API, fetching the generated content and printing it to standard output or appending it to an existing `.gitignore` file.


title: CAVEATS
content:
This command relies on an active internet connection to communicate with the `gitignore.io` web service. It is not a core Git command but rather a community-contributed utility or shell script that wraps the web service's API. The exact options and behavior might vary slightly depending on the specific implementation of `git-ignore-io` being used, as there isn't one official distribution bundled with Git.


title: USAGE AS A GIT ALIAS
content:
Many developers configure `git-ignore-io` as a Git alias for even quicker access. For example, by adding `ignore = !git-ignore-io` to your Git configuration (e.g., `~/.gitconfig`), you could then run `git ignore java,python` to generate your `.gitignore` file. This integrates the functionality directly into the Git command suite, making it feel like a native Git command.


title: OFFLINE USAGE
content:
While `git-ignore-io` primarily relies on the online service, some advanced implementations might include caching mechanisms or allow for pre-downloading templates to enable limited offline functionality. However, the standard usage requires network connectivity to fetch the latest templates from `gitignore.io`.


title: HISTORY
content:
The `gitignore.io` web service was launched around 2012 by Joe Blau, providing a convenient way to generate `.gitignore` files for various projects. Following its success, numerous command-line wrappers and aliases (often named `git-ignore-io`, `gio`, or similar) emerged in the developer community. These tools were developed to integrate the service seamlessly into command-line workflows, allowing developers to generate and manage `.gitignore` files directly from their terminals without needing to visit the website, thereby enhancing productivity.


title: PARAMETERS
content:
<b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show IMAP traffic and progress details during the upload.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose output, showing only critical messages.<br><br><b>--conf=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a non-standard configuration file for IMAP settings instead of the default Git configuration.<br><br><b>--html-attachment</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate and include an HTML version of the patch as an additional attachment to the email message.<br><br><b>--no-html-attachment</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not include an HTML version of the patch. This is the default behavior.<br><br>


title: DESCRIPTION
content:
The <i>git-imap-send</i> command uploads a mailbox of patches, typically generated by <i>git-format-patch</i>, to a designated IMAP folder. This is particularly useful for workflows where patches are reviewed or archived on an IMAP server instead of being sent directly via SMTP. It reads the mailbox data from standard input and creates new email messages in the specified IMAP folder, allowing other tools or users to access them.<br><br>The command relies on specific IMAP configuration variables set in Git, such as host, user credentials, and the target folder, to establish a connection and perform the upload securely. It serves as an alternative to <i>git-send-email</i> for IMAP-centric workflows.


title: CAVEATS
content:
Requires detailed IMAP server configuration in Git's settings (e.g., <i>imap.host</i>, <i>imap.user</i>, <i>imap.folder</i>). If not properly configured, connection will fail. Patches are uploaded as new messages, not necessarily threaded, which may require specific IMAP client or server behavior to manage related patches effectively.


title: IMAP CONFIGURATION VARIABLES
content:
<i>git-imap-send</i> relies heavily on variables set in your Git configuration (e.g., <i>~/.gitconfig</i> or <i>.git/config</i>).<br><br><b>imap.folder</b>: The IMAP folder where patches will be uploaded (e.g., 'INBOX.patches').<br><b>imap.host</b>: The hostname or IP address of the IMAP server.<br><b>imap.user</b>: The username for authentication with the IMAP server.<br><b>imap.pass</b>: The password for the IMAP server (use with caution, consider Git's credential helper).<br><b>imap.port</b>: The port number for the IMAP server (default 993 for SSL, 143 otherwise).<br><b>imap.sslmode</b>: How to handle SSL/TLS ('none', 'ssl', 'tls').<br><b>imap.prefershtml</b>: A boolean indicating whether to generate HTML versions of patches (for <i>--html-attachment</i>).


title: HISTORY
content:
<i>git-imap-send</i> was introduced early in Git's development as an alternative mechanism to <i>git-send-email</i> for patch submission, catering to workflows that prefer or require uploading patches directly to an IMAP server. It has maintained its core functionality as a specialized tool for IMAP interaction within the Git patch management ecosystem, providing a reliable way to integrate with IMAP-based mail systems.


title: PARAMETERS
content:
<b>start <commit-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Initiates an incremental merge operation with the specified target commit-ish (e.g., branch name, commit hash). This command prepares the repository for the incremental conflict resolution process.<br>Common options for <b>start</b>:<br></i><b>--rebase</b> (-r): <i>Perform the incremental merge using a rebase strategy where possible, instead of pure merge.<br></i><b>--force</b> (-f): <i>Force the start of a new incremental merge, even if one is already in progress.<br></i><b>--keep-empty-commits</b> (-k): <i>Do not prune empty commits created during the incremental process.<br></i><b>--no-cleanup</b>: <i>Do not perform cleanup after the merge is finished.</i><br><br><b>continue</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Proceeds with the next step of the incremental merge. This is typically run after resolving conflicts for a step and staging the changes, similar to <b>git rebase --continue</b>.</i><br><br><b>abort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Discards the ongoing incremental merge operation and returns the repository to the state it was in before <b>git imerge start</b> was invoked.</i><br><br><b>finish</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Finalizes the incremental merge, completing the process and creating the merge commit(s) on the current branch.</i><br><br><b>conflicts</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a list of paths that currently have merge conflicts and need resolution.</i><br><br><b>add <path>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Marks one or more specific file paths as resolved. This tells <b>git-imerge</b> that you have handled the conflicts for these files.</i><br><br><b>unadd <path>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Unmarks one or more specific file paths, indicating they are no longer considered resolved and require further attention.</i><br><br><b>resolved</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists all file paths that <b>git-imerge</b> currently considers resolved for the ongoing merge.</i><br><br><b>unresolved</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists all file paths that <b>git-imerge</b> currently considers unresolved for the ongoing merge.</i><br><br>


title: DESCRIPTION
content:
<i><b>git-imerge</b> is an advanced tool designed to simplify large and complex Git merge operations by breaking them down into smaller, more manageable steps. Instead of resolving all conflicts from a complex merge at once, it guides the user through an incremental process. This approach is particularly valuable in scenarios often referred to as 'merge hell', where a direct <b>git merge</b> would result in overwhelming conflict sets. Internally, <b>git-imerge</b> leverages <b>git bisect</b> to pinpoint commits that introduce conflicts, allowing users to resolve issues one by one, test intermediate states, and ensure a clean, stable merge. This process creates a detailed, traceable history of how conflicts were resolved, offering a robust alternative to manual rebase sequences or large, monolithic merge commits that can obscure resolution steps. It allows for a more controlled and less error-prone resolution of protracted divergence between branches.</i>


title: CAVEATS
content:
<i><br><b>git-imerge</b> is not a core Git command and requires separate installation.<br>It relies heavily on <b>git bisect</b> for its internal operations, which might add overhead compared to a simple <b>git merge</b> for straightforward cases.<br>The detailed history created by <b>git-imerge</b>, while useful for auditing conflict resolution, can result in a more complex commit graph with numerous intermediate merge commits.<br>Users should be comfortable with basic Git operations and conflict resolution before attempting complex <b>git-imerge</b> workflows.</i>


title: WORKFLOW OVERVIEW
content:
<i>A typical <b>git-imerge</b> workflow involves starting an incremental merge with <b>git imerge start</b>, resolving conflicts in small batches, staging the changes, and then advancing to the next step with <b>git imerge continue</b>. This cycle repeats until all conflicts are resolved, at which point <b>git imerge finish</b> is used to finalize the merge operation. Commands like <b>git imerge add</b> and <b>git imerge unresolved</b> assist in managing the state of conflict resolution.</i>


title: INTERNAL MECHANISM
content:
<i>At its core, <b>git-imerge</b> intelligently uses <b>git bisect</b> to identify the specific commits that introduce conflicts. It then applies partial merges or rebases to resolve these conflicts incrementally. This systematic approach allows it to build up the final merge commit step-by-step, ensuring that each increment is a resolvable and testable unit of change.</i>


title: HISTORY
content:
<i><b>git-imerge</b> was developed by Michael Haggerty to address the significant challenges of 'merge hell' in large, long-running feature branches, particularly in complex projects where traditional <b>git merge</b> often led to unmanageable conflict sets. Its motivation was to provide a robust and systematic way to make such complex merges tractable by breaking them down into smaller, testable steps, offering a more resilient alternative to manual rebase sequences or squashing complex merge histories into a single commit. It gained traction in environments dealing with continuous integration and large codebases where maintaining a clean yet detailed merge history was crucial.</i>


title: SYNOPSIS
content:
<b>git info</b> [<I>options</I>] [<I>path</I>]<br><br>While some custom implementations may accept options like <i>--verbose</i> or a specific <i>path</i>, most common versions of <i>git-info</i> are designed to operate without any arguments, summarizing the current repository.


title: DESCRIPTION
content:
<i>git-info</i> is not a standard command distributed with Git. Instead, it is a commonly user-defined alias or a custom shell script designed to provide a quick, consolidated overview of the current Git repository. Its typical output includes information such as the current branch, the last commit details (hash, author, message, date), the remote origin URL, and a summary of the working directory's state (e.g., number of untracked, modified, or staged files, and stashes). The exact features and output format can vary widely depending on the specific script or alias implementation used by an individual or team. It serves as a convenient utility for developers to quickly grasp the essential context of their repository without running multiple <i>git</i> commands.


title: CAVEATS
content:
The behavior and output of <i>git-info</i> are entirely dependent on its specific implementation, as it is a custom script or alias rather than a core Git command. Users should be aware that <i>git-info</i> on one system may function differently or provide different information than on another. There is no official man page or standard for its options or output.


title: COMMON OUTPUT
content:
Typical output for <i>git-info</i> often includes:<br><i>Current branch name</i><br><i>Last commit hash and message</i><br><i>Author and date of the last commit</i><br><i>Remote origin URL</i> (e.g., GitHub, GitLab)<br><i>Summary of changes in the working directory</i> (untracked, modified, staged files)<br><i>Number of stashed changes</i>


title: USAGE AS AN ALIAS
content:
Many users implement <i>git-info</i> as a Git alias in their ~/.gitconfig file. For example:<br><b>[alias]</b><br><b>  info = !sh -c 'some_script_that_gets_repo_info'</b><br>or simply map it to a locally installed script executable in their PATH named <b>git-info</b>.


title: HISTORY
content:
The concept of <i>git-info</i> emerged from the Git community's desire for a single, convenient command to quickly inspect the state of a repository. As Git gained widespread adoption, developers often found themselves running a series of commands (like <b>git status</b>, <b>git branch</b>, <b>git remote -v</b>) to get a full picture. This led to the creation of numerous personal scripts and aliases, collectively known as <i>git-info</i>, to automate this process. Its development is decentralized, driven by individual user needs rather than a formal project.


title: SYNOPSIS
content:
<b>git init</b> [-b <branch-name> | --initial-branch=<name>] [--bare] [--template=<template-directory>] [--separate-git-dir=<git-dir>] [--shared[=<permissions>]] [--object-format=<format>] [<directory>]


title: PARAMETERS
content:
<b><directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The directory where the Git repository should be created or reinitialized. If omitted, the current directory is used.<br><br><b>-b <branch-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name for the initial branch in the newly created repository instead of the default name (e.g., 'main' or 'master'). This is an alias for <I>--initial-branch</I>.<br><br><b>--initial-branch=<name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <I>-b</I>, specifies the name for the initial branch. This overrides the <I>init.defaultBranch</I> configuration.<br><br><b>--bare</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a 'bare' repository. This type of repository does not have a working directory, meaning no files are checked out. Bare repositories are typically used as central repositories on servers for sharing among multiple developers.<br><br><b>--template=<template-directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory from which templates will be used. These templates are copied into the new <I>.git</I> directory and can include custom hooks or Gitignore patterns.<br><br><b>--separate-git-dir=<git-dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a Git repository in a specified directory, but store the actual <I>.git</I> directory contents in <I>&#60;git-dir&#62;</I> instead. This allows the working tree and the Git directory to be separate.<br><br><b>--shared[=<permissions>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the repository permissions (e.g., group-writable). This is useful when multiple users need to interact with the same repository on a shared filesystem. Permissions can be 'false', 'true', 'umask', 'group', 'all', or octal digits.<br><br><b>--object-format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the object format for the repository, such as 'sha1' (default) or 'sha256'. This determines the hash algorithm used for Git objects.<br><br>


title: DESCRIPTION
content:
The <I>git init</I> command creates a new empty Git repository or reinitializes an existing one. It is typically the first command you run when starting a new project that you want to put under version control. When executed, <I>git init</I> creates a subdirectory named <I>.git</I> within the current working directory (or the specified <I>&#60;directory&#62;</I>). This <I>.git</I> directory contains all the necessary repository infrastructure: objects, refs (pointers to commits like branches and tags), templates, hooks, and configuration files. It doesn't create any files in the working directory itself.<br><br>The command can also be used to reinitialize an existing repository. In this case, it doesn't remove the existing repository content, but rather adds missing parts or moves the <I>.git</I> directory if <I>--separate-git-dir</I> is used. For shared environments, the <I>--shared</I> option can be used to set permissions appropriately.<br><br>There are two main types of repositories created by <I>git init</I>: a standard repository with a working directory, and a <I>bare</I> repository, which consists only of the <I>.git</I> directory content and is primarily used as a central repository for collaboration (e.g., on a server).


title: CAVEATS
content:
When reinitializing an existing repository, <I>git init</I> is a safe operation; it will not overwrite or destroy existing repository content, only add missing parts or move the <I>.git</I> directory if specified. However, using <I>--bare</I> on an existing non-bare repository can lead to unexpected behavior if not handled carefully, as it effectively removes the working tree context. Always ensure you understand the implications of creating bare repositories, especially when dealing with existing data.


title: DEFAULT BRANCH NAME
content:
Traditionally, <I>git init</I> created a default branch named <I>master</I>. However, in recent Git versions and due to industry trends, the default name has largely shifted to <I>main</I>. You can configure the desired default branch name globally using <I>git config --global init.defaultBranch &#60;name&#62;</I>, or specify it directly for a specific repository using the <I>--initial-branch</I> option during initialization.


title: BARE VS. NON-BARE REPOSITORIES
content:
Understanding the difference between bare and non-bare repositories is crucial. A non-bare repository (the default) contains both the <I>.git</I> directory and a working directory where your project files reside. A bare repository, created with <I>--bare</I>, contains only the <I>.git</I> directory's contents and no working directory. Bare repositories are primarily used as remote repositories that developers clone from and push to, serving as a central hub without being a development environment itself.


title: HISTORY
content:
The <I>git init</I> command has been a fundamental part of Git since its very first public release by Linus Torvalds. It is the cornerstone for starting any new Git-managed project. A notable recent development, starting around Git version 2.28 (mid-2020), is the shift in the default initial branch name. Historically, the default branch created by <I>git init</I> was <I>master</I>. However, due to ongoing discussions about inclusive naming, many projects and Git hosting services (like GitHub) have moved towards <I>main</I> as the default. Git now supports configuring this default via the <I>init.defaultBranch</I> configuration option, or by explicitly using the <I>--initial-branch</I> (or <I>-b</I>) option during initialization.


title: SYNOPSIS
content:
<i>`git-init-db` is an internal Git command and is not intended for direct user invocation. Its functionality is integrated into the `git init` command. Therefore, a standard synopsis for direct use is not applicable.</i>


title: PARAMETERS
content:
<b><i>(None)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>As an internal command, `git-init-db` does not expose user-facing parameters. All configuration and options for repository initialization are handled by the `git init` command.</i><br><br>


title: DESCRIPTION
content:
<i><br>The `git-init-db` command is an <b>internal</b> Git plumbing command that handles the low-level initialization of a Git repository's core database structure. This includes creating the necessary directory structure within the <b>.git/</b> folder (like <b>objects/</b>, <b>refs/</b>, <b>HEAD</b>, <b>config</b>, etc.) that forms the foundation of a Git repository.<br><br>It is <b>not</b> a command intended for direct user invocation. Its functionality has been fully integrated into the higher-level, user-facing `git init` command. When you run `git init`, Git internally performs the operations that `git-init-db` conceptually represents to set up a new, empty repository. Users should always use `git init` to create a new Git repository.</i>


title: CAVEATS
content:
<i>`git-init-db` is a <b>plumbing</b> command of Git, meaning it's a low-level operation primarily used by other Git commands and scripts, not by end-users directly.<br><br>In modern Git versions, its functionality is entirely subsumed by `git init`, which provides a more robust and user-friendly interface for creating new repositories. Direct invocation of `git-init-db` is generally not possible or recommended and may lead to unexpected behavior or errors as it lacks the higher-level checks and options provided by `git init`.</i>


title: PLUMBING VS. PORCELAIN
content:
<i>`git-init-db` exemplifies a <b>'plumbing'</b> command in Git – a low-level command that operates directly on the repository's internal data structures. These commands are typically used by other Git commands (the <b>'porcelain'</b> commands like `git init`) or by scripts that need fine-grained control. End-users generally interact with porcelain commands, which abstract away the complexities of plumbing commands.</i>


title: HISTORY
content:
<i>Historically, `git-init-db` was a distinct internal command responsible for the low-level creation of the Git repository's core database structure. Over time, its functionality was integrated into the higher-level `git init` command to simplify repository creation for users. While the underlying logic conceptually persists, it is no longer exposed as a separate, callable command in typical Git distributions. This integration streamlined the repository setup process and provided a more comprehensive initialization routine under a single command.</i>


title: SYNOPSIS
content:
<b>git instaweb</b> [<I>--local</I>] [<I>--httpd=&lt;command&gt;</I>] [<I>--port=&lt;port&gt;</I>] [<I>--browser=&lt;browser&gt;</I>] [<I>--config=&lt;name&gt;=&lt;value&gt;</I>] [<I>--start</I>] [<I>--stop</I>] [<I>--restart</I>] [<I>--dry-run</I>] [<I>--default</I>]


title: PARAMETERS
content:
<b><I>--local</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Binds the web server only to the local IP address (127.0.0.1).<br><br><b><I>--httpd=&lt;command&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the HTTP daemon to use. Common choices include <i>lighttpd</i>, <i>apache2</i>, <i>webrick</i>, or <i>python</i>.<br><br><b><I>--port=&lt;port&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port number for the web server to listen on. Default is usually 1234.<br><br><b><I>--browser=&lt;browser&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the web browser to launch. Uses the system default if not specified.<br><br><b><I>--config=&lt;name&gt;=&lt;value&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes a configuration variable directly to the web server being launched.<br><br><b><I>--start</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the web server (this is the default action if no other action is specified).<br><br><b><I>--stop</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops a currently running <i>git-instaweb</i> server instance.<br><br><b><I>--restart</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts a running <i>git-instaweb</i> server.<br><br><b><I>--dry-run</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what commands would be executed without actually starting or stopping the server.<br><br><b><I>--default</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the currently specified <i>--httpd</i> and <i>--port</i> the default for future <i>git-instaweb</i> invocations, persisting them in Git configuration.<br><br>


title: DESCRIPTION
content:
<i>git-instaweb</i> is a convenient Git command that sets up and starts a local web server to browse the current Git repository in a web browser. It automates the process of making your repository's history, commits, branches, and files viewable through a simple web interface. This command typically leverages lightweight web servers like Lighttpd, Apache, Webrick, or Python's built-in HTTP server, detecting which is available on your system. It automatically launches your default web browser to the correct URL once the server is running. This functionality is invaluable for quick, on-the-fly repository exploration, sharing a local view of a project, or demonstrating Git features without needing a full-fledged Git web frontend. When you exit, <i>git-instaweb</i> gracefully stops the server process, cleaning up temporary resources. It provides a quick and accessible way to visualize your project's history and structure.


title: CAVEATS
content:
Requires a compatible web server (like lighttpd, apache2, webrick, or python) to be installed and available on the system.<br>Binding to privileged ports (below 1024) may require elevated permissions.<br>The web interface provided is basic and not intended for public production use like a full Git hosting solution.<br>Ensure the chosen browser or its executable is in your system's PATH.


title: CONFIGURATION PERSISTENCE
content:
You can configure <i>git-instaweb</i>'s default behavior by setting Git configuration variables. For instance, <b>git config --global instaweb.httpd lighttpd</b> will make Lighttpd your preferred web server for <i>instaweb</i> globally. Similarly, <b>git config --global instaweb.port 8000</b> will set a default port. The <b>--default</b> option is a convenient shortcut to persist the current <i>--httpd</i> and <i>--port</i> settings for future use.


title: SUPPORTED WEB SERVERS
content:
<i>git-instaweb</i> has built-in detection and support for several common web servers: <i>lighttpd</i>, <i>apache2</i>, <i>webrick</i> (Ruby's simple server), and <i>python</i>'s built-in HTTP server. It attempts to find an available one in your system's PATH. If none are found, it may default to the Python server or prompt an error. You can explicitly specify your choice using the <i>--httpd</i> option.


title: HISTORY
content:
<i>git-instaweb</i> was introduced to Git around version 1.5.0 in late 2006, aiming to simplify local repository browsing. Its primary goal was to provide a quick, temporary web interface for Git repositories without requiring complex manual web server setup. Initially, it often leveraged <i>gitweb</i> (Git's official CGI-based web interface) by setting up a minimal environment for it. Over time, support for various lightweight and commonly available web servers like Lighttpd, Webrick, and Python's built-in server was added, reflecting a broader compatibility and ease-of-use focus. Its development has consistently targeted a frictionless user experience for quick, on-the-fly repository inspection.


title: PARAMETERS
content:
<b><b>install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets up Git LFS by installing Git hooks (e.g., `pre-push`, `post-checkout`, `post-merge`) that manage LFS pointers and files. It's usually the first command you run once per user account on a machine to enable LFS functionality.<br><br><b><b>track</b> <i><pattern></i> [...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tells Git LFS to track files matching one or more specified patterns (e.g., `*.psd`, `*.zip`). This command adds or updates entries in your `.gitattributes` file, indicating that these files should be stored via LFS when committed.<br><br><b><b>untrack</b> <i><pattern></i> [...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops Git LFS from tracking files matching one or more patterns. This removes the corresponding entries from `.gitattributes`. Note that this does not remove the actual large files from LFS storage if they were already committed.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows which files are currently being tracked by Git LFS in your working directory and staging area, along with their LFS status (e.g., whether they are clean or modified).<br><br><b><b>ls</b> [<i><ref></i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists LFS files in a given Git revision (defaulting to `HEAD`). It displays the file path, their size, and their OID (Object ID) in the LFS store.<br><br><b><b>migrate</b> <i><subcommand></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides powerful subcommands (e.g., `import`, `export`, `info`) to rewrite Git history. This allows converting existing large files in standard Git commits to LFS pointers, or vice-versa. Use with caution as it alters repository history and should be done carefully, ideally on a fresh clone.<br><br><b><b>pull</b> [<i><remote></i>] [<i><ref></i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads Git LFS files for the specified Git ref or the current branch. Normally, LFS files are pulled automatically by standard Git commands like `git clone` or `git checkout`.<br><br><b><b>push</b> [<i><remote></i>] [<i><ref></i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uploads Git LFS objects to the remote LFS store for the specified Git ref or the current branch. This is typically triggered automatically during a `git push` operation.<br><br><b><b>config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints Git LFS configuration settings. This can include settings from `.git/config`, global Git configuration, or environment variables, useful for debugging LFS behavior.<br><br><b><b>env</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about the Git LFS environment, including version, Git configuration, OS details, and LFS server URLs. This command is valuable for diagnostics.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed version of Git LFS.<br><br>


title: DESCRIPTION
content:
<i>git-lfs</i> (Git Large File Storage) is an open-source Git extension that allows Git to handle large files more efficiently.<br><br>Traditional Git is optimized for text-based code and struggles with large binary files (e.g., videos, audio, graphics, datasets) because it stores every version of every file directly in the repository's history. This often leads to slow clones, bloats the repository size, and makes operations like fetching and checking out branches sluggish.<br><br><i>git-lfs</i> addresses this by replacing large files in your Git repository with small text pointers. The actual file contents are stored on a remote LFS server (which can be hosted alongside your Git repository, e.g., GitHub, GitLab, Bitbucket). When you clone a repository or check out a specific branch, Git LFS transparently downloads only the specific versions of the large files needed for your current checkout.<br><br>This mechanism keeps the Git repository lean and fast, while still allowing developers to manage large assets within their familiar Git workflow, preserving Git's version control benefits.


title: CAVEATS
content:
When using <i>git-lfs</i>, be aware of the following considerations:<br><br><b>Server Dependency</b>: <i>git-lfs</i> requires a compatible LFS server to store the actual file content. Most major Git hosting services (GitHub, GitLab, Bitbucket) provide built-in LFS support.<br><br><b>Migration Complexity</b>: Using `git lfs migrate` to rewrite history can be complex and potentially destructive if not handled carefully. Always back up your repository before performing history rewrites, and ensure all collaborators are aware of the changes.<br><br><b>Storage and Bandwidth Limits</b>: LFS storage and bandwidth are often subject to limits and potential costs on hosting platforms, especially for large projects or high usage.<br><br><b>Atomic Pushes</b>: For a successful `git push`, the Git LFS objects must be successfully uploaded to the LFS server before the corresponding Git commit (which contains the LFS pointer) can be pushed to the Git remote. If the LFS upload fails, the Git push will also fail.


title: TYPICAL WORKFLOW
content:
The common workflow for incorporating <i>git-lfs</i> into your project is as follows:<br><br>1. <b>Install LFS:</b> Run `git lfs install` once per user account on your machine. This sets up necessary Git hooks.<br><br>2. <b>Track Files:</b> In your repository, use `git lfs track "*.ext"` (e.g., `git lfs track "*.psd"`) for each type of large file you want LFS to manage. This command adds an entry to your `.gitattributes` file.<br><br>3. <b>Stage & Commit:</b> Add your large files using `git add <file>` and `git commit -m "Commit message"` as usual. Git LFS automatically replaces the actual file content with a pointer file during the staging process.<br><br>4. <b>Push:</b> When you run `git push`, Git LFS automatically uploads the actual file contents to the configured LFS server, and then pushes the lightweight pointer files to the Git remote.


title: CONFIGURATION
content:
<i>git-lfs</i> primarily relies on Git's `.gitattributes` file to specify which files are managed by LFS. An entry like `*.psd filter=lfs diff=lfs merge=lfs -text` tells Git to use the LFS filter for `.psd` files, ensuring they are handled by LFS.<br><br>Further global or repository-specific configuration can be done via `git config` commands, typically under the `lfs` namespace (e.g., `git config lfs.url https://mylfs.server.com`). Environment variables can also influence LFS behavior.


title: HISTORY
content:
<i>git-lfs</i> was initially developed by GitHub and first publicly released in 2015. It was created to address the growing problem of managing large binary files within Git repositories, a task for which Git was not originally designed. Prior to its existence, developers often resorted to separate file storage solutions, leading to fragmented workflows, or suffered from repository bloat and slow operations. Since its release, <i>git-lfs</i> has been widely adopted across the software development industry and has become the de facto standard for large file management in Git, continually evolving with new features and performance improvements to support diverse use cases.


title: PARAMETERS
content:
<b><I>branch-to-compare</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument specifying the branch to compare against. If omitted, the command typically defaults to comparing against the current branch's configured upstream tracking branch (e.g., <b>origin/main</b> or <b>@{u}</b>). This shows commits that are on the current branch but not on the specified comparison branch.<br><br><b>--stat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Hypothetical)</i> If implemented, displays a diffstat summary for each unique commit, showing the files changed and the number of lines inserted and deleted.<br><br><b>--pretty=<I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Hypothetical)</i> If implemented, formats the output according to the specified <b><I>format</I></b> string, similar to <b>git log --pretty</b> options (e.g., 'oneline', 'fuller', 'format:%h %s').<br><br><b>--no-merges</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Hypothetical)</i> If implemented, excludes merge commits from the output, showing only linear development commits.<br><br><b>-n <I>limit</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Hypothetical)</i> If implemented, limits the number of commits shown to the specified <b><I>limit</I></b>.<br><br>


title: DESCRIPTION
content:
<i>git-local-commits</i> is <b>not</b> a standard, built-in Git command. It is a common name for a custom script or alias that users create to display commits present only on the current local branch. Its typical purpose is to show changes that have not yet been pushed to its configured upstream remote, or commits that diverge from a specified comparison branch. This command helps developers quickly review their unique local development work, identify unpushed changes, or understand the difference between their current branch and another. Because it is user-defined, its exact functionality, available options, and output format depend entirely on its specific implementation by the user or system administrator. Users often create it to streamline their workflow and provide a clear overview of their unshared contributions.


title: CAVEATS
content:
This command is <b>not</b> a standard Git command. Its existence and behavior are entirely dependent on a user-defined script or alias within a particular Git installation. There is no guarantee of its presence, consistent functionality, or specific options across different Git environments or users. Users typically implement it themselves using combinations of other Git commands like <b>git log</b>, <b>git cherry</b>, or <b>git diff</b>.


title: COMMON IMPLEMENTATIONS
content:
Users typically implement <i>git-local-commits</i> by aliasing it to a specific Git command combination in their Git configuration. Common patterns include:<br><br><b>git config --global alias.local-commits 'log @{u}..HEAD'</b><br><i>(Shows commits on HEAD that are not on its upstream branch)</i><br><br><b>git config --global alias.local-commits '!git cherry -v @{u}'</b><br><i>(Shows commits unique to HEAD that are not in upstream, indicating if they are cherry-pickable)</i><br><br>The <b>@{u}</b> (or <b>@{upstream}</b>) refers to the upstream branch configured for the current branch. If no upstream is configured for the current branch, these commands might fail or yield unexpected results.


title: PURPOSE AND USAGE
content:
The primary purpose of a <i>git-local-commits</i> command is to provide a concise overview of the work unique to the current branch. It is an invaluable tool for:<br><ul><li>Reviewing changes before performing a <b>git push</b> to ensure only intended commits are shared.</li><li>Identifying commits that might need to be rebased, squashed, or amended for a cleaner history.</li><li>Understanding the exact divergence of a feature branch from its main development line (e.g., <b>main</b> or <b>develop</b>).</li><li>Preparing for code reviews by listing the exact changes to be reviewed.</li></ul>It significantly aids in maintaining a clean and understandable commit history.


title: HISTORY
content:
The need to quickly identify unpushed or locally unique commits is a common workflow requirement for many Git users. Since Git doesn't provide a single, dedicated command for this exact purpose with a user-friendly output out-of-the-box, developers frequently create custom aliases or scripts. The name <i>git-local-commits</i> (or similar variations like <i>git-unpushed</i>) emerged as a popular, community-driven convention for these personal helper tools, addressing a recurring need for better visibility into local development progress.


title: SYNOPSIS
content:
<b>git-lock</b> <I>subcommand</I> [<I>options</I>] [<I>arguments</I>]<br><br><b>Subcommands:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>lock</b> <I>path</I>...<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>unlock</b> <I>path</I>...<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>status</b> [<I>path</I>...]<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>break</b> <I>path</I>...


title: PARAMETERS
content:
<b><b>lock</b> <I>path</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Acquires an exclusive lock on the specified file(s). If a file is already locked by another user, the command will fail unless overridden.<br><br><b><b>unlock</b> <I>path</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Releases the lock(s) on the specified file(s). Only the lock owner can unlock a file by default.<br><br><b><b>status</b> [<I>path</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current lock status. If <I>path</I> is provided, shows status for specific files; otherwise, lists all currently locked files in the repository.<br><br><b><b>break</b> <I>path</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forcibly releases a lock on the specified file(s), regardless of who owns it. This command typically requires elevated permissions or administrator rights.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'lock' and 'unlock', show what would happen without actually modifying lock status.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;With 'status', show all files that are currently locked in the repository.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce more verbose output, showing details like lock owner, timestamp, etc.<br><br>


title: DESCRIPTION
content:
The <I>git-lock</I> command provides a mechanism for exclusive file locking within a Git repository. Unlike Git's distributed model which excels at merging textual changes, certain files, particularly binary assets or complex project files, do not merge well. <I>git-lock</I> addresses this by allowing a developer to acquire an exclusive lock on a file, preventing other team members from modifying or pushing changes to that specific file until the lock is released. This helps to avoid conflicts and ensures data integrity for non-mergeable assets. The locking mechanism typically relies on a centralized or shared state, which could be managed by a dedicated server, a shared Git reference, or a convention within the repository itself. Users can lock a file, view current locks, and unlock files, including the ability to forcefully break a lock in emergency situations. It acts as an extension to Git, enabling workflows that require strict serialization of changes on particular files.


title: CAVEATS
content:
It is crucial to understand that <I>git-lock</I> is not a standard, built-in Git command. It typically represents an external utility, script, or a feature provided by a specific Git extension (e.g., some forms of Git LFS for binary files). Its implementation requires a centralized or shared mechanism to store lock information, which goes against Git's inherently distributed nature. This means it may require server-side hooks or a dedicated daemon. Locks only prevent others from pushing conflicting changes; they do not prevent local modifications by another user who hasn't pulled the lock information. Stale locks can occur if a user's client crashes or they forget to unlock files, potentially blocking workflow. Force-breaking locks should be used with caution.


title: LOCK STORAGE MECHANISM
content:
The actual implementation of <I>git-lock</I> varies widely. Common approaches include storing lock information in a dedicated branch, a shared file within the repository (e.g., <I>.git/locks</I> or a custom file), a centralized database, or leveraging Git server-side hooks (e.g., pre-receive) to enforce lock rules during push operations.


title: WORKFLOW INTEGRATION
content:
For effective use, <I>git-lock</I> often integrates with Git hooks. A 'pre-commit' hook might warn users about trying to commit a locked file, and a 'pre-push' hook on the server can reject pushes that modify locked files owned by others.


title: HISTORY
content:
The concept of exclusive file locking predates Git, being a common feature in centralized version control systems like SVN or Perforce to prevent concurrent modifications on files that are difficult to merge. With Git's distributed and merge-centric design, explicit locking became less critical for text-based files. However, the challenge of managing binary assets or non-mergeable project files persisted. This led to the development of external tools and conventions to provide a "locking" capability for Git workflows. While Git LFS (Large File Storage) introduced a standard mechanism for locking LFS-tracked files, a general "<I>git-lock</I>" command often refers to custom scripts or third-party extensions designed to extend locking to any file type or to provide a broader locking strategy, addressing specific project needs where merge conflicts on certain files are highly disruptive.


title: PARAMETERS
content:
<b><i>&lt;path&gt;</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more paths to files that should be locked. These files must be tracked by Git LFS.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the lock details in JSON format, which can be useful for scripting or programmatic consumption.<br><br>


title: DESCRIPTION
content:
The command <i>git-locked</i> is not a standard Git or Linux command. This analysis refers to <b>git lfs lock</b>, a subcommand of <i>Git Large File Storage (LFS)</i>.<br><br><b>git lfs lock</b> allows developers to acquire an exclusive lock on files tracked by Git LFS. This is particularly crucial for binary files (like images, audio, or large datasets) where traditional Git merging is ineffective or impossible. By locking a file, a developer signals that they are actively working on it, preventing others from pushing changes to the same file and thus avoiding potential conflicts.<br><br>The locking mechanism is server-side and advisory; it requires a Git LFS server that supports locking. When a file is locked, only the locker can push changes to that file. Other collaborators attempting to push changes to a locked file will be prevented from doing so. The lock must be explicitly released using <b>git lfs unlock</b> once editing is complete.


title: CAVEATS
content:
The command 'git-locked' itself does not exist as a standalone Git or Linux command. This analysis is based on <b>git lfs lock</b>, a subcommand of Git LFS.<br><br>File locking with Git LFS requires both Git LFS to be installed and configured in your repository, and the remote Git LFS server must support the locking API.<br><br>Locks are advisory, meaning they prevent pushes to the locked file on the server, but do not prevent local modifications or merges on a user's machine. Users must still respect the locking convention.


title: LOCKING WORKFLOW
content:
A typical locking workflow involves: 1. A user locks a file using <b>git lfs lock &lt;file&gt;</b>. 2. They make their modifications and commit them locally. 3. They push their changes, which also synchronizes the lock status with the LFS server. 4. Once done, the user unlocks the file using <b>git lfs unlock &lt;file&gt;</b> to allow others to acquire the lock and make changes.


title: ADVISORY NATURE
content:
It's important to understand that Git LFS locks are advisory. They prevent other users from pushing changes to a locked file on the remote server, but they do not prevent local modifications or the creation of conflicting local branches. Adherence to the locking protocol relies on team cooperation.


title: HISTORY
content:
The Git LFS project was initiated by GitHub to handle large files efficiently within Git repositories. The file locking feature was introduced with Git LFS 2.0 in 2017. This addition significantly improved collaborative workflows for projects dealing with binary assets, by addressing the long-standing challenge of managing conflicts in non-mergeable files.


title: SYNOPSIS
content:
<i>git log</i> [<options>] [<revision-range>] [[--] <path>...]<br><br><b>Explanation:</b><br><ul><li><i>&lt;options&gt;</i>: Flags that modify the command's behavior (e.g., formatting, filtering).</li><li><i>&lt;revision-range&gt;</i>: Specifies the range of commits to display (e.g., <i>HEAD~5..HEAD</i>, <i>branch-A..branch-B</i>). If omitted, it shows the history reachable from <i>HEAD</i>.</li><li><i>&lt;path&gt;...</i>: Restricts the log output to commits that modified the specified files or directories. The <i>--</i> separator is used to distinguish paths from revisions or options, especially if a path might resemble an option or revision.</li></ul>


title: PARAMETERS
content:
<b><b>--patch</b>, <b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the patch (diff) for each commit.<br><br><b><b>--stat</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show diffstat (number of files changed, insertions, deletions).<br><br><b><b>--oneline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display each commit on a single line, showing only the SHA-1 hash and commit message.<br><br><b><b>--graph</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Draw an ASCII art graph of the commit history, illustrating merges and branches.<br><br><b><b>--pretty[=&lt;format&gt;]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format the output using predefined styles (e.g., <i>oneline</i>, <i>short</i>, <i>full</i>) or a custom format string.<br><br><b><b>-n &lt;count&gt;</b>, <b>--max-count=&lt;count&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of commits to output.<br><br><b><b>--author=&lt;pattern&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show commits whose author matches the specified pattern.<br><br><b><b>--grep=&lt;pattern&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show commits whose commit message matches the specified pattern.<br><br><b><b>--since=&lt;date&gt;</b>, <b>--until=&lt;date&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit commits to those made after or before a specified date.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all branches, remote-tracking branches, and tags.<br><br><b><b>--follow</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue listing commits along rename detection when a single path is given.<br><br>


title: DESCRIPTION
content:
The <i>git log</i> command is a fundamental tool for examining the history of a Git repository. It provides a chronological list of commits, displaying essential information such as the commit SHA-1 hash, author, date, and commit message. By default, commits are listed in reverse chronological order, showing the most recent commits first.<br><br><i>git log</i> is highly versatile, offering numerous options to filter, format, and visualize the repository's history. Users can narrow down results by author, committer, date range, commit message content, or specific files/directories. It can also display the actual changes (diffs) introduced by each commit, show statistics, or even draw an ASCII art graph representing the branch and merge history. This command is indispensable for understanding how a project has evolved, identifying when and by whom specific changes were introduced, debugging issues, and preparing for code reviews.


title: CAVEATS
content:
For very large repositories with extensive history, running <i>git log</i> without filters can be slow and produce overwhelming output. Using options like <i>--max-count</i>, <i>--oneline</i>, or specific path filters is recommended.<br><br>Understanding the various <i>revision-range</i> syntaxes (e.g., <i>A..B</i> for commits reachable from B but not A, <i>A...B</i> for commits unique to either A or B) is crucial for precise history exploration.<br><br>The <i>--graph</i> output can become complex and difficult to interpret in repositories with highly intricate branching and merging strategies.


title: DEFAULT PAGER
content:
The output of <i>git log</i> is typically piped through a pager program (e.g., <i>less</i> on Linux/macOS, <i>more</i> on Windows), allowing users to scroll through large outputs, search, and navigate. You can exit the pager by pressing 'q'.


title: CUSTOM FORMATTING WITH <I>--PRETTY=FORMAT</I>
content:
This powerful option allows users to define their own output format using placeholders. For example, <i>--pretty=format:"%h %an %ad %s"</i> would show a short hash, author name, author date, and subject (commit message first line) for each commit. This offers unparalleled flexibility for custom scripts or specialized views.


title: HISTORY
content:
<i>git log</i> has been a core command in Git since its inception by Linus Torvalds in 2005. It was designed as the primary interface for users to inspect and navigate the repository's history. Over the years, its functionality has been continuously expanded with more sophisticated filtering, formatting, and visualization options, such as <i>--graph</i> and highly customizable <i>--pretty=format</i>, to meet the evolving needs of developers managing complex codebases. It remains one of the most frequently used Git commands.


title: SEE ALSO
content:
<b>git show(1)</b>: Display various types of objects (commits, tags, trees, blobs)., <b>git diff(1)</b>: Show changes between commits, commit and working tree, etc., <b>git reflog(1)</b>: Manage and show reference log., <b>git blame(1)</b>: Show what revision and author last modified each line of a file., <b>git rev-list(1)</b>: Lists commit objects in reverse chronological order.


title: SYNOPSIS
content:
<i>git ls-files</i> [<i>--cached</i> | <i>--deleted</i> | <i>--others</i> | <i>--modified</i> | <i>--unmerged</i>] [<i>--stage</i>] [<i>-z</i>] [<i>--exclude=&lt;pattern&gt;</i>] [<i>--exclude-from=&lt;file&gt;</i>] [<i>--full-name</i>] [<i>--</i>] [<i>&lt;file&gt;...</i>]


title: PARAMETERS
content:
<b>--cached</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only files that are currently in the index (staged).<br><br><b>--deleted</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only files that have been deleted from the working tree and are marked for removal in the index.<br><br><b>--others</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only untracked files not in the index. These are files present in the working tree but not yet added to Git.<br><br><b>--ignored</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows files that are ignored by Git. Requires <i>--others</i> to be effective.<br><br><b>--modified</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only files that have been modified in the working tree compared to their indexed version.<br><br><b>--unmerged</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only files that have unmerged changes from a Git merge operation. These files are typically in conflict.<br><br><b>--stage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the mode, object name (SHA-1), and stage number in addition to the path. Useful for understanding merge conflicts.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows even more detailed information, primarily for debugging Git internals.<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints file paths null-terminated (instead of newline-terminated), useful for scripting to handle filenames with spaces or special characters.<br><br><b>--exclude=&lt;pattern&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes files matching the given pattern. Can be specified multiple times.<br><br><b>--exclude-from=&lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads exclude patterns from the specified file, similar to .gitignore rules.<br><br><b>--full-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When run from a subdirectory, prints paths relative to the top-level directory instead of the current directory.<br><br><b>--error-unmatch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits with a non-zero status if any specified file pattern does not match any file.<br><br><b>&lt;file&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional file paths or patterns to limit the output to specific files.<br><br>


title: DESCRIPTION
content:
The <i>git ls-files</i> command is a low-level 'plumbing' command used to inspect and list files in Git's index (staging area) and the working tree. It provides detailed information about tracked, untracked, ignored, and deleted files, as well as those currently in merge conflicts. Unlike the higher-level <i>git status</i>, <i>git ls-files</i> is designed for scripting and provides raw data like file modes, object SHA-1s, and stage numbers for each entry. It's invaluable for debugging repository states, verifying index contents, and building custom Git tools or scripts that need precise control over file listings and statuses. By default, it only lists files currently tracked by Git, offering specific options to reveal untracked, ignored, or modified files.


title: CAVEATS
content:
<i>git ls-files</i> is a 'plumbing' command; its output is designed for programmatic parsing rather than human readability. By default, it only lists tracked files and explicitly excludes ignored and untracked files unless the <i>--others</i> or <i>--ignored</i> options are used. Be mindful of its default behavior regarding ignored files, as it can lead to confusion if you expect it to behave like <i>git status</i>.


title: PLUMBING COMMAND
content:
In Git, 'plumbing' commands are low-level commands that are primarily used by other Git commands or by scripts. They are designed to be stable and provide raw data outputs. <i>git ls-files</i> is a classic example, providing the building blocks for higher-level commands like <i>git status</i>.


title: THE GIT INDEX (STAGING AREA)
content:
The Git index, also known as the staging area, is a crucial intermediate layer between your working directory and your repository's history. <i>git ls-files</i> directly queries this index, showing which files are prepared to be committed, their modes, and their object IDs, giving you granular control over what goes into your next commit.


title: HISTORY
content:
<i>git ls-files</i> has been a core component of Git since its inception, providing a foundational way to interact with the Git index. Its design reflects Git's philosophy of providing low-level, composable commands that can be used to build more complex workflows and tools. It remains essential for advanced scripting and understanding the precise state of tracked and untracked files.


title: PARAMETERS
content:
<b><I>repository</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The remote repository to query. This can be the name of a remote configured in your local repository (e.g., <I>origin</I>) or a direct URL to a Git repository (e.g., <I>https://github.com/git/git.git</I>).<br><br><b>[<I>ref-patterns</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional patterns to filter the references displayed. If provided, only references matching these patterns will be shown. For example, <I>heads/main</I> or <I>tags/v1.0</I>.<br><br><b><b>--heads</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the heads (branches) available on the remote.<br><br><b><b>--tags</b>, <b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the tags available on the remote.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show both heads and tags. This is equivalent to specifying both <I>--heads</I> and <I>--tags</I>.<br><br><b><b>--upload-pack=&lt;path&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the <I>git-upload-pack</I> command on the remote host. Useful when the remote Git daemon is not in the standard PATH.<br><br><b><b>--exit-code</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with a non-zero status code if any of the specified <I>ref-patterns</I> were not found on the remote. This is useful for scripting to check for the existence of specific references.<br><br><b><b>--get-url</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the URL for the specified remote and exit. This option doesn't actually query the remote repository.<br><br>


title: DESCRIPTION
content:
<i>git ls-remote</i> is a low-level Git command used to query a remote repository and display the references (like branches and tags) it makes available. Unlike <i>git clone</i> or <i>git fetch</i>, it does not download any objects; it merely lists the SHA-1 hashes and corresponding reference names on the remote. This command is particularly useful for scripting, inspecting the state of a remote repository without fetching its content, or verifying what branches and tags exist before interacting further. You can specify a remote by its name (if it's already configured in your local repository) or directly by its URL. Optional arguments allow you to filter the results, showing only heads (branches), only tags, or specific references that match a given pattern.


title: CAVEATS
content:
<i>git ls-remote</i> is a low-level command primarily for scripting and inspection. Its output format is raw SHA-1 hashes and reference names, which might be less user-friendly compared to higher-level commands like <i>git branch -r</i>. It only lists references and does not fetch any actual Git objects, requiring network access to the remote repository.


title: OUTPUT FORMAT
content:
The output of <i>git ls-remote</i> typically consists of lines, each containing a SHA-1 hash followed by a tab character, and then the full reference name. For example:<br><br>a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0 (tab) refs/heads/main<br><br>For annotated tags, there might be a second line representing the object the tag points to, e.g.:<br><br>a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0 (tab) refs/tags/v1.0<br>b1c2d3e4f5g6h7i8j9k0l1m2n3o4p6q7r8s9t0u1 (tab) refs/tags/v1.0^{}


title: REFERENCE PATTERNS
content:
When specifying <I>ref-patterns</I>, you can use glob-style patterns to filter the references. For instance, <I>heads/*</I> would match all branches, and <I>tags/v*</I> would match all tags starting with 'v'. If no patterns are specified, all references are shown (unless <I>--heads</I> or <I>--tags</I> is used).


title: HISTORY
content:
<i>git ls-remote</i> has been a fundamental part of Git since its early versions. It plays a crucial role in the Git network protocols, specifically during the 'reference advertisement' phase where a client discovers what references a remote repository has available before initiating operations like cloning or fetching. Its core functionality has remained consistent, serving as a stable and essential component for remote repository interaction and discovery.


title: PARAMETERS
content:
<b>--full-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show object names in full, relative to the repository root.<br><br><b>--name-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the names of the entries, one per line.<br><br><b>--name-width=<width></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display entry names padded or truncated to the specified width.<br><br><b>--abbrev[=<n>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Abbreviate the object SHA-1 hashes to <n> digits (default 7).<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show object sizes in bytes for blob entries.<br><br><b>--z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Terminate entries with a NUL byte instead of a newline, useful for scripting.<br><br><b><tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The tree object to inspect. Can be a commit, tag, branch name, or a direct tree hash.<br><br><b><path>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional paths to filter the output, showing only entries within these paths.<br><br>


title: DESCRIPTION
content:
The <b>git-ls-tree</b> command is a "plumbing" command used to list the contents of a given <i>tree object</i> in Git. A tree object represents a directory in the Git repository, containing references to other tree objects (subdirectories) and <i>blob objects</i> (files).<br><br>For each entry in the specified tree, <b>git-ls-tree</b> outputs its mode, object type (blob, tree, or submodule), the SHA-1 hash of the object, and the filename. This command is crucial for understanding the exact state and structure of a directory at a particular point in history, without needing to check out the entire content. It's often used in scripts or for low-level repository inspection, allowing developers to programmatically navigate the Git object database. Unlike <b>git ls-files</b>, which lists files in the index, <b>git-ls-tree</b> operates directly on tree objects, which can be part of a commit, a tag, or even a standalone tree object.


title: CAVEATS
content:
<b>git-ls-tree</b> lists tree and blob objects as they are recorded in the Git database; it does not reflect the current state of the working directory or the index, unless the <tree-ish> argument specifically points to the tree object associated with <i>HEAD</i> or the current index. Its output is optimized for machine parsing, making it less human-readable by default. Submodules are listed with mode `160000` and their commit SHA-1, not their internal contents.


title: PLUMBING COMMAND
content:
<b>git-ls-tree</b> is considered a "plumbing" command, meaning it operates at a low level directly on Git's internal data structures. These commands are typically used by scripts or other Git commands rather than directly by end-users. This distinguishes it from "porcelain" commands, which are more user-friendly and abstract the underlying mechanics.


title: MODES IN OUTPUT
content:
The output includes a mode field, which indicates the type of object and its permissions. Common modes include <i>100644</i> (regular file), <i>100755</i> (executable file), <i>040000</i> (subdirectory - another tree object), and <i>160000</i> (gitlink - a submodule).


title: HISTORY
content:
<b>git-ls-tree</b> is a fundamental "plumbing" command that has been a core part of Git since its early development. Conceived by Linus Torvalds, Git was built around a content-addressable filesystem where all data (files, directories, commits) are objects identified by their SHA-1 hash. Commands like <b>ls-tree</b> were essential from the outset to inspect and interact with these basic object types. Its purpose, to list the contents of a tree object, directly reflects Git's internal data model, making it a stable and enduring utility within the Git command suite. Its primary use remains in low-level scripting and repository inspection, consistent with its original design as a building block for higher-level Git commands.


title: SEE ALSO
content:
git cat-file(1), git show(1), git rev-parse(1), git read-tree(1), git write-tree(1), git ls-files(1)


title: SYNOPSIS
content:
<i>As <b>git-magic</b> is not a standard command, there is no universal synopsis.<br>If it exists as a custom script or alias, its usage would depend entirely on its implementation. Typically, custom Git commands follow the pattern <b>git magic [options] [arguments]</b>, where <b>magic</b> is the name of the script or alias.</i>


title: DESCRIPTION
content:
<i>The command <b>git-magic</b> is not a standard Git subcommand or a common Linux utility distributed with Git. It is highly probable that this name refers to a custom script, an alias configured by a user, or a metaphorical term used to describe advanced or less-understood Git operations. Developers often create custom scripts or aliases (e.g., <b>git config alias.magic '...'</b>) to automate complex or frequently used Git workflows that might seem 'magical' due to their power and conciseness. Examples of such 'magic' operations include interactive rebasing, powerful reflog usage, or complex cherry-picking scenarios. Without a specific implementation, its functionality cannot be defined.</i>


title: CAVEATS
content:
<i>Users should be aware that <b>git-magic</b> is not part of the official Git distribution. If encountered, its behavior is entirely dependent on its creator's implementation. Running unknown scripts can pose security risks or lead to unintended repository state changes. Always verify the source and purpose of any non-standard Git commands or aliases before execution.</i>


title: UNDERSTANDING GIT ALIASES
content:
<i><b>Git aliases</b> are custom shortcuts for Git commands. They are defined in the Git configuration file (e.g., <b>~/.gitconfig</b>) using <b>git config alias.<name> '<command>'</b>. For example, <b>git config alias.st 'status -sb'</b> allows you to type <b>git st</b> instead of <b>git status -sb</b>. A custom <b>git-magic</b> could be an alias for a series of commands or a shell script.</i>


title: THE REFLOG
content:
<i>Often considered 'magic,' the <b>git reflog</b> is a powerful safety net. It records every change to your repository's <b>HEAD</b> and branch tips, allowing you to recover lost commits or revert almost any unintended action. It's not part of your commit history but a local log of where your <b>HEAD</b> has been.</i>


title: INTERACTIVE REBASE
content:
<i><b>git rebase -i</b> (interactive rebase) allows you to rewrite commit history by reordering commits, squashing them, editing messages, splitting commits, or deleting them entirely. This powerful feature is often perceived as 'magic' for its ability to clean up a messy commit history before merging into a main branch.</i>


title: HISTORY
content:
<i>The concept of 'Git magic' in development typically refers to advanced Git features that can significantly simplify complex version control tasks, often appearing almost effortless or 'magical' to those unfamiliar with their underlying mechanisms. While no single command named <b>git-magic</b> has a specific history within Git's development, the practice of creating custom aliases and scripts to encapsulate complex workflows has been prevalent since Git's early days. This allows users to personalize their Git experience and streamline their command-line interactions, making powerful operations more accessible and less verbose.</i>


title: PARAMETERS
content:
<b><I>&lt;msg&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the mail message file to be parsed. This file typically contains one or more email messages or patch files formatted as standard emails.<br><br>


title: DESCRIPTION
content:
The <b>git-mailinfo</b> command is a Git <i>plumbing</i> command used to parse a mail message (e.g., an email or a patch file) and extract essential header information: the sender's identity, the message date, and the subject line.<br><br>It is primarily used internally by other Git commands, such as <b>git-am</b>, which utilizes it to construct commit messages when applying patches from a mailbox. It reads the mail message from the specified file and prints the extracted information to standard output in a structured format suitable for programmatic consumption.<br><br>While not typically invoked directly by end-users, it's a fundamental component in Git's mail-handling capabilities, ensuring consistent processing of email-based patches.


title: CAVEATS
content:
<b>git-mailinfo</b> is a <i>plumbing</i> command, meaning it is designed for internal use by Git scripts and other Git commands. Its output format is stable but intended for programmatic parsing rather than direct human readability. It expects input in a standard mail message format and may not behave as expected with malformed or non-standard input.


title: HISTORY
content:
<b>git-mailinfo</b> is an integral part of Git's mail-based patch workflow, a core feature of Git since its early development. It was developed to reliably parse and extract metadata from email-formatted patches, facilitating the `git-am` command's ability to apply patches from a mailbox. Its existence underscores Git's strong support for distributed workflows reliant on email-based communication and patch exchange.


title: SYNOPSIS
content:
git mailsplit [-b] [-d <I>dir</I>] [-o <I>file</I>] [-q] [-f <I>N</I>] [-k] [-s] [-p] [-v] [--encoding=<I>encoding</I>] [--detect-encoding] [--[no-]decode-header] [--[no-]base64-decode-body] [--[no-]quopri-decode-body] [ < <I>mbox</I> ]


title: PARAMETERS
content:
<b>-b, --bare</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Store individual messages in <I>msgNNNN</I> files directly in the target directory, without creating a <I>mbox</I> subdirectory.<br><br><b>-d <I>dir</I>, --directory <I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where the split messages should be written. Defaults to <I>mbox</I> in the current working directory.<br><br><b>-o <I>file</I>, --output <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the template for output file names. The default is <I>msg%04d</I>, which creates files like <I>msg0001</I>, <I>msg0002</I>.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress progress messages.<br><br><b>-f <I>N</I>, --first-number <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start numbering the output files from <I>N</I> instead of 1.<br><br><b>-k, --keep-cr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not remove carriage return (CR) characters from the end of lines. By default, <B>git-mailsplit</B> removes CRs.<br><br><b>-s, --no-mboxrd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to parse the <I>mboxrd</I> format, which escapes 'From ' lines. Treat all 'From ' lines as message separators, even if they are quoted.<br><br><b>-p, --patch-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;In addition to splitting messages, also store the patch parts of the messages in separate files named <I>msgNNNN.patch</I> in the output directory.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show verbose progress messages during splitting.<br><br><b>--encoding=<I>encoding</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input character encoding for the mailbox file (e.g., <I>UTF-8</I>, <I>ISO-8859-1</I>).<br><br><b>--detect-encoding</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to automatically detect the character encoding of the input mailbox file.<br><br><b>--[no-]decode-header</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control whether MIME-encoded headers (e.g., Subject, From) are decoded. Default is to decode.<br><br><b>--[no-]base64-decode-body</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control whether base64-encoded parts of the email body are decoded. Default is to decode.<br><br><b>--[no-]quopri-decode-body</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control whether quoted-printable encoded parts of the email body are decoded. Default is to decode.<br><br>


title: DESCRIPTION
content:
The <B>git-mailsplit</B> command reads a standard Unix mailbox file (mbox) from standard input and splits it into individual email messages. Each message is then written to a separate file in a designated output directory, typically named in a sequential fashion like <I>msg0001</I>, <I>msg0002</I>, etc. This utility is primarily used as a pre-processor for <B>git am</B> (apply a series of patches from a mailbox) when developers receive patch series via email in a single mbox file. It ensures that <B>git am</B> can process each patch individually, maintaining the integrity of the patch series workflow.


title: CAVEATS
content:
Handling of various mbox formats and their subtle differences (e.g., <I>mboxo</I>, <I>mboxrd</I>) can sometimes lead to issues. While <B>git-mailsplit</B> tries to be robust, malformed or non-standard mbox files might not be processed correctly. Encoding detection and decoding also depend on the input quality and declared MIME types within the emails. Users should verify the output, especially for complex or multi-part messages.


title: USAGE SCENARIO
content:
A common usage of <B>git-mailsplit</B> is piping the content of an mbox file directly into it. For example, to split an mbox file named <I>patches.mbox</I> into a directory named <I>my-patches</I>, you would use: <I>cat patches.mbox | git mailsplit -d my-patches</I>. After splitting, you can then navigate into <I>my-patches</I> and use <I>git am *</I> to apply all the patches.


title: OUTPUT STRUCTURE
content:
By default, <B>git-mailsplit</B> creates a directory named <I>mbox/</I> (or the directory specified by <I>-d</I>) in the current working directory. Inside this directory, it places the split email messages, typically named <I>msg0001</I>, <I>msg0002</I>, and so on. If the <I>--patch-file</I> option is used, corresponding patch files (e.g., <I>msg0001.patch</I>) will also be created for messages containing patch content.


title: HISTORY
content:
<B>git-mailsplit</B> is an integral part of Git's robust email-based patch workflow, which has been a core feature of Git since its early days. It was designed to facilitate the common practice of sending and receiving software patches via email, allowing developers to consume a series of patches received in a single mailbox file, often generated by mailing list archives or email clients. Its development has focused on improving robustness in handling various mbox formats and character encodings to ensure seamless integration with the <B>git am</B> command.


title: SYNOPSIS
content:
<b>git maintenance</b> &lt;subcommand&gt; [&lt;options&gt;]<br><br><b>git maintenance run</b> [--[no-]auto] [--[no-]fetch] [--[no-]gc] [--[no-]commit-graph] [--[no-]loose-objects]<br><b>git maintenance start</b> [--auto | --manual]<br><b>git maintenance stop</b><br><b>git maintenance status</b><br><b>git maintenance list</b><br><b>git maintenance register</b><br><b>git maintenance unregister</b>


title: PARAMETERS
content:
<b><b>run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes maintenance tasks immediately based on the current configuration. You can specify which tasks to run using individual task options.<br><br><b><b>start</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Begins periodic background maintenance. By default, it attempts to use automatic system scheduling (like <i>systemd</i> or <i>launchd</i>). Use <b>--manual</b> for a simple background process.<br><br><b><b>stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Halts periodic background maintenance and unregisters it from system schedulers if it was started automatically.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current status of background maintenance, indicating whether it's running and its configuration.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the maintenance tasks that are currently enabled or configured to run automatically.<br><br><b><b>register</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Registers <i><b>git-maintenance</b></i> with system-level schedulers (e.g., <i>systemd timers</i>, <i>launchd agents</i>) to enable automatic background maintenance. This is often done implicitly by <b>start</b>.<br><br><b><b>unregister</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unregisters <i><b>git-maintenance</b></i> from system-level schedulers. This is often done implicitly by <b>stop</b>.<br><br><b><b>--auto</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>start</b> or <b>run</b> to indicate that automatic system scheduling mechanisms should be used or considered. This is the default for <b>start</b>.<br><br><b><b>--manual</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>start</b> to indicate that <i><b>git-maintenance</b></i> should not try to use system schedulers, but instead run as a simple background process which relies on a manual scheduling (e.g., a <i>cron</i> job or a continuously running daemon that checks schedule internally).<br><br><b><b>--[no-]fetch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables the prefetch task (fetching objects from remotes) during <b>run</b> or in the auto-maintenance configuration.<br><br><b><b>--[no-]gc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables the garbage collection task (repacking and pruning) during <b>run</b> or in the auto-maintenance configuration.<br><br><b><b>--[no-]commit-graph</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables the commit-graph update task during <b>run</b> or in the auto-maintenance configuration.<br><br><b><b>--[no-]loose-objects</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables the loose-objects pruning task during <b>run</b> or in the auto-maintenance configuration.<br><br>


title: DESCRIPTION
content:
<i><b>git-maintenance</b></i> is a command introduced in Git 2.37 designed to automate common Git repository maintenance tasks. Its primary goal is to keep your Git repositories performing optimally and reduce disk usage without requiring manual intervention.<br><br>It handles tasks like: <i>garbage collection</i> (pruning loose objects and repacking), updating the <i>commit graph</i> for faster history traversal, and <i>prefetching</i> objects from remote repositories to keep them up-to-date. By regularly performing these operations in the background, <i><b>git-maintenance</b></i> helps improve the speed of common Git commands (like <b>git status</b>, <b>git log</b>) and ensures data integrity. Users can start, stop, or manually run these maintenance operations, as well as configure their frequency and behavior.


title: CAVEATS
content:
<i><b>git-maintenance</b></i> requires Git version 2.37 or later. Its automatic scheduling mechanism (<b>--auto</b>) relies on OS-specific features (like <i>systemd timers</i> on Linux, <i>launchd agents</i> on macOS, or a custom background process), which might require appropriate permissions for setup and can behave differently across platforms. Running maintenance tasks, especially garbage collection (<b>gc</b>), can be resource-intensive (CPU, disk I/O) and might impact performance during execution. The <b>prefetch</b> task can also generate network traffic. Ensure your system's scheduling services are operational for reliable automatic maintenance.


title: CONFIGURATION
content:
The behavior of <i><b>git-maintenance</b></i>, especially in <b>--auto</b> mode, is controlled by Git configuration variables. These include: <i><b>maintenance.auto</b></i> (boolean, enables/disables auto maintenance for a repository), <i><b>maintenance.strategy</b></i> (determines how auto-maintenance is scheduled, e.g., 'auto' for system services, 'manual' for a simple background process), <i><b>maintenance.schedule</b></i> (e.g., 'hourly', 'daily', 'weekly', 'monthly', 'never' to set frequency).<br><br>Individual task settings like <i><b>maintenance.auto.gc</b></i>, <i><b>maintenance.auto.commit-graph</b></i>, <i><b>maintenance.auto.prefetch</b></i>, and <i><b>maintenance.auto.loose-objects</b></i> (all booleans) allow enabling or disabling specific tasks within the automatic maintenance schedule.


title: TASKS OVERVIEW
content:
<i><b>git-maintenance</b></i> performs several key tasks:<br><b>gc</b>: Runs <i>garbage collection</i>, which includes <i>repacking</i> loose objects into packfiles and <i>pruning</i> unreferenced objects, reducing disk space and improving performance.<br><b>commit-graph</b>: Updates the <i>commit-graph</i> file, which significantly speeds up operations that traverse commit history, such as <b>git log</b> and <b>git blame</b>.<br><b>prefetch</b>: Fetches objects from configured remotes, keeping the local repository's branches and references up-to-date with remote changes.<br><b>loose-objects</b>: Specifically prunes loose objects that are no longer referenced, an important part of overall garbage collection.


title: HISTORY
content:
<i><b>git-maintenance</b></i> was introduced in <b>Git 2.37</b> (released in Q3 2022). Prior to this, Git lacked an integrated, cross-platform solution for automating routine repository maintenance. Users had to manually set up <i>cron jobs</i> or similar schedulers to run commands like <b>git gc</b>. The introduction of <i><b>git-maintenance</b></i> aimed to simplify this process, providing a built-in mechanism that could intelligently manage background tasks, adapt to different operating system scheduling paradigms, and ensure repositories remained optimized without constant user oversight. Subsequent Git versions have refined its capabilities, notably adding the <b>prefetch</b> task and improving its scheduling robustness.


title: SEE ALSO
content:
git gc(1), git repack(1), git prune(1), git commit-graph(1), cron(8), systemd.timer(5), launchd.plist(5)


title: SYNOPSIS
content:
<b>git merge</b> [<options>] <commit>...<br><b>git merge</b> [<options>] <branch name><br><b>git merge</b> --abort<br><b>git merge</b> --continue


title: PARAMETERS
content:
<b><commit>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The names of commits, typically branch names, to be merged into the current branch.<br><br><b>-n, --no-summary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress showing a short summary of how the branches are merged.<br><br><b>--stat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a diffstat at the end of the merge.<br><br><b>--no-commit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the merge, but do not create a merge commit, allowing the user to inspect the changes and make further adjustments.<br><br><b>--no-ff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a merge commit even when a fast-forward merge is possible, preserving the branch's history.<br><br><b>--ff-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only perform the merge if it can be resolved as a fast-forward. If not, refuse to merge.<br><br><b>--squash</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce a single commit result from the changes of the merged branch, without recording the merge itself. The history of the merged branch is not integrated.<br><br><b>-s <strategy></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the given merge strategy. Common strategies include <i>recursive</i> (default), <i>ours</i>, and <i>octopus</i>.<br><br><b>-X <option></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass strategy-specific options. E.g., -Xours to prefer 'ours' changes on conflicts for recursive strategy.<br><br><b>-m <msg></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the commit message for the merge commit.<br><br><b>--abort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Abort the current merge in progress, restoring the branch to its state before the merge attempt.<br><br><b>--continue</b><br>&nbsp;&nbsp;&nbsp;&nbsp;After resolving conflicts during a merge, use this to commit the changes and complete the merge operation.<br><br><b>--allow-unrelated-histories</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows merging branches that do not share a common ancestor. Useful when merging two independent repositories.<br><br><b>--autostash</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically stash and unstash local modifications before and after the merge.<br><br>


title: DESCRIPTION
content:
The <i>git-merge</i> command is a fundamental Git operation used to combine divergent lines of development. When you merge, Git takes two (or more) separate histories and combines them into a single, new history. This is typically done by creating a new "merge commit" that has multiple parent commits—one for each branch being merged. <br><br>Git handles merges in two primary ways: <i>fast-forward merges</i> and <i>three-way merges</i>. A fast-forward merge occurs when the current branch's tip is an ancestor of the target branch's tip; Git simply moves the current branch pointer forward to the target branch's tip without creating a new commit. A three-way merge, on the other hand, is required when the histories have diverged. Git identifies a common ancestor, then combines changes from both branches relative to that ancestor, creating a new merge commit. <br><br>If Git cannot automatically resolve differences, a <i>merge conflict</i> occurs, requiring manual intervention to resolve the conflicting changes before the merge can be completed.


title: CAVEATS
content:
Merge operations can introduce <i>merge conflicts</i> when the same lines of code have been changed differently in the branches being merged. These conflicts must be resolved manually before the merge can be completed. While <i>git-merge</i> aims to preserve history, using options like <b>--squash</b> will rewrite history by discarding the individual commits from the merged branch and creating a single new commit, which can complicate debugging or code archaeology. Always be mindful of the implications of fast-forward vs. non-fast-forward merges on your repository's history graph. Merging branches with unrelated histories requires the <b>--allow-unrelated-histories</b> option, which should be used with caution as it bypasses a safety check.


title: MERGE STRATEGIES
content:
Git offers several merge strategies to handle different merging scenarios. The <i>recursive</i> strategy is the default and most commonly used, handling complex three-way merges with options to resolve conflicts (e.g., preferring 'ours' or 'theirs'). The <i>ours</i> strategy resolves any conflicting changes by preferring the changes from the current branch. The <i>octopus</i> strategy is used for merging more than two heads simultaneously. The <i>subtree</i> strategy is useful for managing a subdirectory as a separate repository.


title: FAST-FORWARD VS. NON-FAST-FORWARD MERGES
content:
A <i>fast-forward</i> merge occurs when the current branch's tip is an ancestor of the branch being merged. Git simply moves the current branch pointer forward, effectively 'fast-forwarding' it. This doesn't create a new merge commit. A <i>non-fast-forward</i> merge (often enforced with <b>--no-ff</b>) creates a new merge commit even if a fast-forward was possible. This preserves the history of the merged branch and clearly shows where a feature branch was integrated, which can be useful for understanding project history.


title: RESOLVING MERGE CONFLICTS
content:
When <i>git-merge</i> encounters conflicting changes, it pauses the merge process and marks the files with conflict markers (e.g., &lt;&lt;&lt;&lt;&lt;&lt;&lt;, =======, &gt;&gt;&gt;&gt;&gt;&gt;&gt;). You must manually edit these files to resolve the conflicts. After resolving, you use <b>git add &lt;file&gt;</b> to stage the changes, and then <b>git merge --continue</b> to complete the merge. <b>git status</b> is invaluable during conflict resolution to see which files are conflicted.


title: HISTORY
content:
<i>git-merge</i> is a core command that has been part of Git since its inception in 2005. It's fundamental to Git's distributed nature, enabling developers to integrate work from different branches and contributors. Over time, new merge strategies like <i>recursive</i> (which became the default) were added to handle more complex scenarios, and options like <b>--allow-unrelated-histories</b> (introduced in Git 2.9) were added to address common usage patterns and safety concerns. Its evolution reflects the ongoing refinement of Git's ability to manage complex project histories efficiently.


title: SYNOPSIS
content:
<b>git merge-base</b> [--all] <I>commit</I> <I>commit</I>...<br><b>git merge-base</b> --octopus <I>commit</I>...<br><b>git merge-base</b> --independent <I>commit</I>...<br><b>git merge-base</b> --is-ancestor <I>commit</I> <I>commit</I><br><b>git merge-base</b> --fork-point <I>rev</I> [<I>rev</I>]


title: PARAMETERS
content:
<b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output all common ancestors, not just the best one. This can result in multiple lines of output.<br><br><b>--octopus</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Find a common merge base for an N-way merge (octopus merge). This finds the common ancestor of all specified commits and reports the best ones that are not ancestors of each other.<br><br><b>--independent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identify independent commit chains that are not ancestors of each other. These are typically the tips of merge bases found by <I>--octopus</I> mode when multiple independent merge bases exist.<br><br><b>--is-ancestor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check if the first commit is an ancestor of the second commit. Exits with 0 status code if true, 1 otherwise. No output is produced.<br><br><b>--fork-point</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Find a common ancestor using the <I>reflog</I> to approximate where a branch diverged from another. This is useful for rebasing a series of private commits that were originally based on an upstream branch, even if the upstream branch has been rebased itself.<br><br>


title: DESCRIPTION
content:
The <I>git merge-base</I> command helps in finding a good common ancestor between two or more commits. It's primarily used internally by <I>git merge</I> and <I>git rebase</I> to determine the common point from which changes diverged. For a standard two-branch merge (<I>git merge A B</I>), <I>git merge-base A B</I> typically finds the single common ancestor. This ancestor is crucial for performing a 3-way merge, where changes from both branches are applied relative to this common base.<br><br>When there are multiple common ancestors, <I>git merge-base</I> intelligently selects the "best" common ancestor, usually the one that is an ancestor of all other common ancestors. This ensures that the merge is based on the most recent shared history. The command also supports modes for finding common ancestors for N-way merges (<I>--octopus</I>), identifying independent heads (<I>--independent</I>), and checking ancestry relationships (<I>--is-ancestor</I>). Understanding <I>git merge-base</I> is key to grasping how Git handles branching and merging operations internally.


title: CAVEATS
content:
In scenarios with complex histories like "criss-cross merges" (where two branches merge and then one of the merged branches merges back into the other, creating diamond shapes in the history), there might be multiple "best" common ancestors. <I>git merge-base</I> attempts to find the most appropriate one but its choice might not always be what a human intuitively expects in highly convoluted graphs. When given more than two commits without <I>--octopus</I> or <I>--independent</I>, it finds a common ancestor of all of them, which can also lead to less intuitive results in specific graph configurations compared to a simple two-commit merge base.


title: BEST COMMON ANCESTOR
content:
When multiple common ancestors exist between two commits, <I>git merge-base</I> selects the 'best' one. This 'best' ancestor is defined as the unique common ancestor that is an ancestor of all other common ancestors. This ensures that the merge base is the most recent shared point in the history that precedes both branches, minimizing the set of changes that need to be merged.


title: USAGE WITH MULTIPLE COMMITS
content:
When <I>git merge-base</I> is given more than two commits without the <I>--octopus</I> or <I>--independent</I> options, it finds a common ancestor of all of them. This is internally handled by computing the merge base of the first two commits, then finding the merge base of that result with the third commit, and so on. This process aims to identify a single point in history that precedes all specified branches.


title: HISTORY
content:
The <I>git merge-base</I> command is a fundamental "plumbing" utility within Git's architecture, designed to find common ancestors. It has been a core component since the early days of Git, forming the basis for higher-level commands like <I>git merge</I> and <I>git rebase</I>. Its various modes (<I>--octopus</I>, <I>--independent</I>, <I>--is-ancestor</I>) have been added over time to address increasingly complex merging scenarios and to provide more granular control over ancestry queries.


title: SYNOPSIS
content:
git merge-file [-L <label1> [-L <label2> [-L <label3>]]] [-p | --diff3 | --original] [--union] [-q | --quiet] [--marker-size=<n>] [--] <current-file> <base-file> <other-file>


title: PARAMETERS
content:
<b>-L <label></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use specified labels instead of file names for conflict markers. Up to three labels can be given for <current-file>, <base-file>, and <other-file> respectively.<br><br><b>-p<br>--diff3</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a <I>diff3</I> style merge, meaning the base version content is shown in the middle of conflict markers.<br><br><b>--original</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <I>--diff3</I>, but includes information about the original source in the conflict header.<br><br><b>--union</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate conflict markers. Instead, add the conflicting lines from all participants to the output, which may result in uncompilable code.<br><br><b>-q<br>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress diagnostic output when conflicts occur.<br><br><b>--marker-size=<n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of '#' characters used in conflict markers. The default is 7.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the end of options; treats subsequent arguments as file names, useful if file names start with '-'.<br><br><b><current-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The 'ours' version of the file (the one being merged into). The result of the merge is written to this file.<br><br><b><base-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The common ancestor of <current-file> and <other-file>.<br><br><b><other-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The 'theirs' or 'remote' version of the file.<br><br>


title: DESCRIPTION
content:
<I>git-merge-file</I> is a low-level Git command that performs a 3-way merge on three provided files: a common base version, the 'ours' version, and the 'theirs' (or 'remote') version. It is a fundamental component used internally by Git's higher-level merge mechanisms, such as <I>git merge</I>.<br><br>The command takes these three file paths as arguments and attempts to combine their changes into a single output file, typically written to the 'ours' file. If conflicts occur where changes overlap, <I>git-merge-file</I> inserts conflict markers into the output, allowing the user to resolve them manually. This tool is rarely invoked directly by end-users but is crucial for understanding how Git resolves divergences between branches.


title: CAVEATS
content:
<b>Plumbing Command</b>: <I>git-merge-file</I> is a plumbing command; it operates directly on file paths and does not interact with the Git index or repository history. Users rarely invoke this command directly.<br><br><b>Textual Merges Only</b>: This command only handles textual merges. For binary files, Git's higher-level merge tools typically defer to specific binary merge strategies or signal a conflict.


title: MERGE STRATEGY
content:
<I>git-merge-file</I> employs a line-based merge strategy. It identifies common lines, insertions, and deletions between the three versions to produce the merged output. It's designed to be robust against various changes like line endings and whitespace differences (though it doesn't automatically normalize them).


title: CONFLICT MARKERS
content:
When conflicts occur, the output file will contain special markers indicating the conflicted regions. The default markers typically look like:<br><pre>&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD<br><I>    content from current-file</I><br>=======<br><I>    content from other-file</I><br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; branch-name</pre><br>The <I>--diff3</I> option adds a section for the <I>base-file</I> content, providing more context for resolution:<br><pre>&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD<br><I>    content from current-file</I><br>||||||| base-file<br><I>    content from base-file</I><br>=======<br><I>    content from other-file</I><br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; branch-name</pre>


title: HISTORY
content:
<I>git-merge-file</I> has been a core component of Git since its early days, predating many of the higher-level porcelain commands. It implements the standard 3-way merge algorithm, which is a foundational concept in version control systems. Its existence as a separate, low-level command allows Git to modularize its merge logic, making it robust and reusable.


title: PARAMETERS
content:
<b>--reread-full-tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>git-merge-index</i> to re-read the entire index from disk before processing, rather than relying on its in-memory cache. This can be useful if the index might have been modified by another process outside of <i>git-merge-index</i>.<br><br><b>&lt;merge_program&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the external merge program that <i>git-merge-index</i> should invoke for each file that needs merging. This program is expected to take specific arguments (typically paths to the common ancestor, 'ours', and 'theirs' versions of the file, and the output path) and resolve the conflict.<br><br><b>&lt;arguments_to_merge_program&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any additional arguments that should be passed directly to the <i>merge_program</i>. These arguments follow the <i>merge_program</i> itself.<br><br>


title: DESCRIPTION
content:
<i>git-merge-index</i> is a low-level <b>"plumbing"</b> command in Git, primarily used internally by higher-level merge commands like <i>git merge</i>. Its main purpose is to manage the Git index during a three-way merge operation. When <i>git merge</i> encounters a conflict, <i>git-merge-index</i> is responsible for invoking an external merge program (specified by <i>merge_program</i>) for each conflicted file. It prepares the index entries (stage 1 for common ancestor, stage 2 for 'ours', and stage 3 for 'theirs') for the external tool. <br><br>After the external tool completes, <i>git-merge-index</i> updates the working tree with the tool's output, and then stages the resolved content back into the index. This command doesn't perform the merge itself; it orchestrates the process of resolving conflicts by delegating to a user-configured or default merge tool. It's a crucial component for enabling flexible conflict resolution using various external diff/merge utilities configured via <i>git config merge.tool</i>. It effectively bridges the gap between Git's internal index representation of conflicts and the user's preferred method for conflict resolution.


title: CAVEATS
content:
<i>git-merge-index</i> is a plumbing command, meaning it's designed for internal Git operations and script usage, not for direct interactive use by end-users. Incorrect usage can lead to a corrupted index or working tree state. It relies on the specified <i>merge_program</i> to correctly handle file merging and return a zero exit status upon success; otherwise, it treats the merge as failed.


title: INDEX STAGES FOR CONFLICT RESOLUTION
content:
<i>git-merge-index</i> primarily interacts with the three conflict stages in the Git index: stage 1 (the common ancestor version of the file), stage 2 (the 'ours' version, from the current branch), and stage 3 (the 'theirs' version, from the branch being merged). It extracts these versions for the external merge tool.


title: EXTERNAL MERGE TOOL INVOCATION
content:
The <i>merge_program</i> is invoked with specific arguments that represent the different file versions (ancestor, ours, theirs) and the output path. After the tool completes, <i>git-merge-index</i> examines its exit status and the output file to update the index and working tree accordingly.


title: WORKING TREE UPDATE
content:
Upon successful resolution by the <i>merge_program</i>, <i>git-merge-index</i> updates the working directory file with the merged content and clears the conflict entries from the index, replacing them with a single, resolved entry.


title: HISTORY
content:
<i>git-merge-index</i> has been a fundamental part of Git's merge machinery since its very early days. It was introduced as a core component to enable the robust three-way merge strategy and the integration of external merge tools. Its design reflects Git's philosophy of providing low-level plumbing commands that can be composed to build higher-level <b>"porcelain"</b> commands. Over time, its functionality has remained consistent as the underlying mechanism for handling index entries during merges, adapting to minor changes in Git's internal object model and index format.


title: PARAMETERS
content:
<b>&lt;prefix&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the subdirectory that represents the subtree within the superproject. This is the directory where the subtree's contents reside.<br><br><b>&lt;commit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional) The specific commit or branch from the superproject's history whose changes should be merged into the subtree. If omitted, the script might default to the current HEAD or a predefined reference.<br><br>


title: DESCRIPTION
content:
The `git-merge-into` command is typically a helper script, not a core Git command distributed with Git itself. It is often found as a community-contributed utility or part of older `git-subtree` implementations designed to manage sub-repositories within a larger Git project.<br><br>Its primary purpose is to integrate changes from the superproject (the main repository) into a specific subdirectory that is being managed as a Git subtree. This process involves effectively creating commits in the subtree's localized history (within the superproject) that reflect changes from the superproject's history. This is particularly useful when you've developed features or fixes in the main project that you wish to propagate back to the original upstream repository of the subtree, allowing the subtree's maintainers to incorporate these updates.<br><br>Unlike `git subtree merge`, which pulls changes <i>from</i> the subtree's remote into the superproject, `git-merge-into` facilitates the reverse flow of historical changes <i>into</i> the subtree's representation. Given its non-standard nature, its exact implementation and available options may vary depending on the specific script being used.


title: CAVEATS
content:
<ul><li><b>git-merge-into</b> is <b>not a standard Git command</b>. It is typically a custom script or a helper from older `git-subtree` setups. Its availability and behavior may vary significantly.</li><li>Incorrect usage can lead to complex history issues or conflicts within the subtree's history. Users should understand the implications of merging changes across different histories.</li><li>Modern `git subtree` commands (like `git subtree push` for propagating changes) might offer alternative or more robust ways to achieve similar goals without needing a separate `git-merge-into` script.</li><li>Always back up your repository or work on a disposable branch before using non-standard or complex history manipulation commands.</li></ul>


title: PURPOSE IN SUBTREE WORKFLOW
content:
In a typical `git-subtree` workflow, changes made directly within the subtree's directory in the superproject are considered part of the superproject's history. To push these changes (or other superproject changes relevant to the subtree) back to the original upstream repository of the subtree, a common approach is to first "merge" these superproject changes <i>into</i> the subtree's specific history (the part of the superproject's history that corresponds to the subtree). This prepares a clean commit for the subtree that can then be pushed to its remote, making the superproject's changes available to the subtree's independent development.


title: ALTERNATIVE APPROACHES
content:
For propagating changes from the superproject to a subtree's upstream, `git subtree push` is often used. This command effectively squashes the relevant superproject commits into a single commit for the subtree and pushes it. While `git-merge-into` aims to create a more direct merge commit reflecting superproject changes within the subtree's history, `git subtree push` offers a simpler, though potentially less granular, method for synchronization. Alternatively, using `git submodules` or external package managers might be more suitable for managing dependencies in certain scenarios.


title: HISTORY
content:
The concept behind `git-merge-into` stems from the challenges of managing external dependencies or subprojects in Git before the widespread adoption of `git-submodule` or more robust `git-subtree` implementations. Early solutions often involved custom scripts to handle specific merging or pushing scenarios that were not natively supported or were cumbersome. While `git-subtree` evolved to include commands for pulling and pushing subtree changes, a dedicated `git-merge-into` script emerged in some communities to specifically address the propagation of superproject changes into the subtree's history, often for direct pushing to the subtree's upstream. Its usage has become less common as `git-subtree` and other dependency management tools matured.


title: PARAMETERS
content:
<b><i>&lt;base&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the common ancestor version of the file. This represents the state of the file before divergent changes were made on 'ours' and 'theirs' branches.<br><br><b><i>&lt;ours&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to our version of the file. This is the content of the file from the current branch or working tree.<br><br><b><i>&lt;theirs&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to their version of the file. This is the content of the file from the branch being merged into 'ours'.<br><br><b><i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional path to the file in the working tree. This argument is crucial when <i>git-merge-one-file</i> is used as a merge driver, as it allows the script to query Git's configuration (e.g., <b>merge.&lt;driver&gt;.name</b>) based on the file's attributes or context. The merged content might also be written to this path.<br><br>


title: DESCRIPTION
content:
<i>git-merge-one-file</i> is a low-level, internal Git helper script designed to perform a 3-way merge operation on a single file. Unlike user-facing commands like <b>git merge</b>, this script is not typically invoked directly by end-users. Instead, it serves as a plumbing command that can be used by other Git components, such as <b>git mergetool</b>, or more commonly, as a custom merge driver configured via <b>.gitattributes</b>.<br><br>It takes three versions of a file—the common ancestor (base), our version (ours), and their version (theirs)—and attempts to combine them. If the merge is successful, the merged content is usually written to standard output or directly into the specified working tree path. If conflicts arise, it attempts to mark them using standard Git conflict markers.<br><br>Its primary purpose is to provide a reusable primitive for merging individual files, allowing Git to delegate specific merge logic for particular file types or scenarios.


title: CAVEATS
content:
This command is an internal Git plumbing script and is generally not meant for direct invocation by end-users. Its behavior and specific arguments can vary slightly between Git versions or even depending on how it's integrated within a specific Git installation (e.g., if it's a shell script in <b>contrib/</b>). It relies on Git's internal merge machinery and configuration to perform its task, especially when acting as a custom merge driver.


title: RETURN VALUE
content:
The script typically exits with a status code of <b>0</b> if the merge is successful and no conflicts remain. A non-zero exit code (e.g., <b>1</b>) indicates that conflicts were detected and the merged output contains conflict markers, or that an error occurred during the merge process.


title: USAGE AS CUSTOM MERGE DRIVER
content:
One of the most common applications of <i>git-merge-one-file</i> is as a custom merge driver. This allows users to define specific merge strategies for particular file types. To do this, you would:<br>1. Configure a merge driver in your Git configuration (e.g., <b>.git/config</b> or <b>~/.gitconfig</b>):<br>   <pre>[merge "your-driver-name"]<br>   name = Your Custom Merge Driver<br>   driver = /path/to/git-merge-one-file %O %A %B %L %P</pre><br>   Note: The parameters for <b>driver</b> are standard for Git merge tools (<b>%O</b>=base, <b>%A</b>=ours, <b>%B</b>=theirs, <b>%L</b>=output, <b>%P</b>=path), and <i>git-merge-one-file</i> expects them in a specific order.<br>2. Associate the driver with file patterns in <b>.gitattributes</b>:<br>   <pre>*.your_extension merge=your-driver-name</pre><br>This setup ensures that when Git merges files matching <b>*.your_extension</b>, it will invoke your custom driver, which in turn leverages <i>git-merge-one-file</i> to perform the actual 3-way merge.


title: HISTORY
content:
The concept behind <i>git-merge-one-file</i> has been fundamental to Git's merge strategy since its early days. As Git evolved, the need for a standardized, reusable component to handle single-file merges became apparent, especially for custom merge drivers. While often implemented as a shell script in the <b>contrib/</b> directory of the Git source, its role is to provide a clean interface for external tools or internal components to leverage Git's powerful 3-way merge capabilities on a granular, per-file basis, without needing to understand the complexities of full repository merging.


title: SYNOPSIS
content:
<i>git-merge-repo</i> &lt;source_repo_url&gt; &lt;source_branch&gt; [&lt;target_path&gt;] [<i>options</i>]<br><br><i><b>Note:</b> This is a conceptual synopsis for a common user-defined script or operation, not a standard command. Its actual syntax and capabilities depend entirely on the specific implementation used.</i>


title: PARAMETERS
content:
<b><i>&lt;source_repo_url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL or local path to the Git repository whose history is to be merged.<br><br><b><i>&lt;source_branch&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific branch from the source repository to be merged.<br><br><b><i>[&lt;target_path&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The path within the current repository where the contents of the source repository should reside. If omitted, the source's content might be merged into the root.<br><br><b>[<i>options</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Placeholder for any implementation-specific options, such as `--no-commit`, `--squash`, or options related to history rewriting.<br><br>


title: DESCRIPTION
content:
The term <b>git-merge-repo</b> does not refer to a standard, built-in Git command. Instead, it typically describes a common, advanced Git operation or a custom script designed to merge the complete history of an independent Git repository, or a specific subdirectory within it, into another existing repository.<br><br>The primary goal is often to consolidate separate projects into a single, unified repository while preserving their full commit histories. This task is more complex than a standard branch merge, as it involves integrating fundamentally different project histories and potentially rewriting parts of the commit graph to fit the new structure. Common methods to achieve this involve sophisticated use of commands like <i>git subtree</i>, <i>git filter-branch</i>, <i>git remote</i>, <i>git fetch</i>, and <i>git read-tree</i>.


title: CAVEATS
content:
Because <b>git-merge-repo</b> is a custom operation rather than a standard command, its usage comes with significant caveats:<br><b>Complexity:</b> It often involves intricate Git commands and can be challenging to execute correctly, especially for those unfamiliar with advanced Git history manipulation.<br><b>History Rewriting:</b> Many implementations involve rewriting commit history, which can be disruptive and dangerous in shared repositories if not handled with extreme care. Always back up your repository before attempting such operations.<br><b>Repository Size:</b> Merging full histories can significantly increase the size of your repository, as all objects from the merged history are retained.<br><b>Merge Conflicts:</b> Integrating disparate histories can lead to complex and numerous merge conflicts that require careful resolution.<br><b>Maintenance:</b> If the merged repository was intended to be updated regularly from the source, setting up a robust, maintainable workflow (e.g., with <i>git subtree</i>) is crucial.


title: COMMON USE CASES
content:
<b>Consolidating Projects:</b> Merging several independent Git repositories into a single, unified monorepo, where each original repo becomes a subdirectory.<br><b>Migrating Subdirectories:</b> Extracting a subdirectory from one repository and moving it, with its full commit history, into a new location (often the root) of another repository.<br><b>Integrating External Codebases:</b> Incorporating a third-party library or framework's development history directly into your project's main repository.


title: TYPICAL IMPLEMENTATION APPROACHES
content:
<b>Using <i>git subtree</i>:</b> The recommended modern approach. It allows embedding a subproject into your repository as a subdirectory. It can import history and push/pull changes relatively easily.<br><b><i>git filter-branch</i> with <i>git read-tree</i>:</b> A powerful but complex method. Involves fetching the source repository, then using <i>git filter-branch</i> to rewrite its history (e.g., prefixing all paths) before merging it into the target repository.<br><b>Manual <i>git remote</i>, <i>git fetch</i>, and <i>git cherry-pick</i>/<i>rebase</i>:</b> A more manual approach suitable for smaller, controlled merges, where specific commits are picked from the source repository's history and applied to the target.


title: HISTORY
content:
The concept of merging entire repository histories predates specific tool support. Early Git users often resorted to manual sequences of commands like <i>git remote add</i>, <i>git fetch</i>, and <i>git read-tree</i>, followed by careful commits and potentially <i>git filter-branch</i> to adjust paths or prune unwanted history.<br><br>The need for a more streamlined approach led to the development of custom scripts and aliases (often named conceptually like <i>git-merge-repo</i>) to automate these complex steps. The introduction of <i>git subtree</i> in Git 1.7.11 (July 2012) provided a more robust and officially supported mechanism for managing subprojects within a superproject, significantly simplifying many scenarios that previously required ad-hoc <i>git-merge-repo</i> scripts. Despite this, bespoke scripts are still common for highly specific or one-off repository consolidation tasks.


title: SEE ALSO
content:
git merge(1), git remote(1), git fetch(1), git subtree(1), git filter-branch(1), git read-tree(1), git rebase(1)


title: PARAMETERS
content:
<b><base-tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The common ancestor tree ID or reference.<br><br><b><local-tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The 'our' side tree ID or reference.<br><br><b><remote-tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The 'their' side tree ID or reference.<br><br><b>--write-tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the merged tree to the object database and print its ID. This is the default behavior if conflicts are resolved.<br><br><b>--name-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List paths of modified or conflicting files instead of writing a tree. It does not resolve conflicts; it reports them by name.<br><br>


title: DESCRIPTION
content:
<i>git-merge-tree</i> is a <I>plumbing</I> command used to perform a three-way merge between two <I>tree-ish</I> objects, given a common base <I>tree-ish</I>. It computes the object ID of the resulting merged tree or lists affected paths. This command is typically not used directly by end-users but serves as a low-level building block for higher-level merge commands like <I>git-merge-recursive</I>. It takes the object IDs of the base, local, and remote trees as arguments. The merge process considers entries at the same path from all three trees and produces a combined tree. If conflicts occur for a given path, special conflict markers are typically placed, or the conflicted path is omitted if the <I>--name-only</I> option is used. The command effectively simulates a merge without updating the working directory, making it useful for scripting and internal Git operations that need to compute a merged tree state.


title: CAVEATS
content:
This is a <I>plumbing</I> command, primarily for internal Git use or scripting, not for direct end-user interaction.<br>It only merges <I>trees</I>, not working directories. It computes the resulting tree object but does not modify files in the working directory or update the index.<br>It does not automatically resolve all conflicts. Conflicted paths might be omitted or marked depending on options and internal logic.


title: PURPOSE AS A PLUMBING COMMAND
content:
<i>git-merge-tree</i> is a "plumbing" command, which means it's designed to be used as a building block for higher-level "porcelain" commands or scripts. It operates on fundamental Git objects (trees) and provides raw output, making it suitable for automated processes rather than direct interactive use by end-users.


title: OUTPUT FORMAT
content:
By default, <i>git-merge-tree</i> outputs the object ID of the newly created merged tree. If the <i>--name-only</i> option is used, it instead outputs a list of paths that are modified or conflict, indicating which files would be affected by the merge.


title: THREE-WAY MERGE LOGIC
content:
The command performs a three-way merge by comparing the <i>local</i> and <i>remote</i> trees against their <i>base</i> common ancestor. It identifies changes unique to <i>local</i>, changes unique to <i>remote</i>, and common changes. It then combines these changes, resolving non-conflicting differences automatically.


title: HISTORY
content:
<i>git-merge-tree</i> has been part of Git's core plumbing commands for a long time, serving as a fundamental component for its three-way merge capabilities. Its design reflects Git's philosophy of providing low-level, composable tools. It's often called internally by higher-level merge strategies to compute the merged state of different branches. Its primary purpose has remained consistent: to perform the core logic of a three-way tree merge, abstracting away the details of file-level content merging.


title: SYNOPSIS
content:
<i>Not for direct user invocation.</i><br><B>git-mergetool--lib</B> is an internal library script sourced by other Git commands, primarily <B>git mergetool</B>, to provide common functionalities. It does not have a user-facing command-line synopsis.


title: PARAMETERS
content:
<b><i>N/A</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;As an internal library script, <B>git-mergetool--lib</B> does not accept command-line parameters in the traditional sense. Its functions are called with arguments by the scripts that source it.<br><br>


title: DESCRIPTION
content:
<B>git-mergetool--lib</B> is an internal library script used by the <B>git mergetool</B> command. It provides a collection of common functions and utilities to facilitate the integration and invocation of various external merge tools (e.g., KDiff3, Meld, Beyond Compare) within the Git workflow. This script handles tasks such as parsing merge tool configurations from Git's configuration files, identifying available merge tool paths, and constructing the appropriate command-line arguments for launching the selected tool.<br>It is not intended for direct user execution but is sourced by <B>git mergetool</B> and its helper scripts to abstract away the complexities of tool-specific invocation details, ensuring a consistent interface for merge resolution.


title: CAVEATS
content:
<B>git-mergetool--lib</B> is an internal component of Git. It is not designed for direct user interaction or invocation. Its internal functions, interfaces, and behavior may change without prior notice across Git versions, as it is subject to the internal development and refactoring of the <B>git mergetool</B> command. Users should interact with merge functionality exclusively through the public <B>git mergetool</B> command.


title: INTERNAL USAGE
content:
<B>git-mergetool--lib</B> is typically invoked by other Git scripts using the `.` (dot) or `source` shell built-in command. This makes its functions and variables available in the calling script's environment. For example, <B>git mergetool</B> might use `source "$(git --exec-path)/git-mergetool--lib"`. This allows it to define functions like `run_merge_tool` or `get_merge_tool_cmd` that are then called by the main <B>git mergetool</B> logic.


title: HISTORY
content:
<B>git-mergetool--lib</B> emerged as part of the ongoing effort to improve and standardize external merge tool integration within Git. As the <B>git mergetool</B> command evolved to support a wide array of tools and configuration options, centralizing common helper functions into a dedicated library script like <B>git-mergetool--lib</B> became necessary. This modular approach helps in maintaining the codebase, adding new tool support, and ensuring consistent behavior across different merge tool invocations within Git.


title: PARAMETERS
content:
<b><I>remote</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the remote repository to compare against. If omitted, defaults to the upstream remote of the current branch (e.g., <I>origin</I>).<br><br><b><I>branch</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The local branch to check for missing commits. If omitted, defaults to the current active branch (HEAD).<br><br>


title: DESCRIPTION
content:
<b>git-missing</b> is a utility, commonly provided by the <b>git-extras</b> package, that helps identify commits present in one Git reference (typically a local branch) but absent from another (often its remote tracking branch). It's particularly useful for determining which commits need to be pushed to a remote repository. By comparing two points in history, it provides a concise list of commits that are 'missing' from the target reference, simplifying complex <b>git log</b> commands often used for comparing divergenced histories.


title: CAVEATS
content:
<b>git-missing</b> is not a standard Git command bundled with Git itself. It's typically provided by third-party packages like <b>git-extras</b>. Its availability and exact behavior can vary depending on the installed version or custom scripts. It primarily shows commits that are <I>local</I> but not <I>remote</I> (i.e., commits to push). To see commits that are <I>remote</I> but not <I>local</I> (i.e., commits to pull), other commands like <b>git log ..@{upstream}</b> or <I>git-unpulled</I> (from <b>git-extras</b>) are more appropriate.


title: COMPARISON LOGIC
content:
<b>git-missing</b> typically compares the specified local branch (or current branch) against its remote tracking branch (e.g., <I>HEAD</I> vs. <I>@{upstream}</I>). It identifies commits reachable from the local reference but not from the remote reference. This helps in quickly seeing what work is still pending to be synchronized with the remote.


title: OUTPUT
content:
The output of <b>git-missing</b> usually mimics <I>git log --oneline</I>, showing commit hashes and subject lines. This concise format makes it easy to quickly review which commits are yet to be pushed or are unique to the local branch.


title: HISTORY
content:
<b>git-missing</b> emerged as a practical utility script, often part of community-contributed collections like <b>git-extras</b>, to simplify common Git comparison tasks. Before such scripts, users would frequently rely on complex <b>git log</b> invocations (e.g., <I>git log @{upstream}..HEAD --oneline</I>) to achieve the same result. Its development reflects the community's desire for more user-friendly aliases and wrappers for everyday Git operations, abstracting away the intricacies of direct <b>git log</b> arguments for specific comparison scenarios.


title: SEE ALSO
content:
git-log(1), git-diff(1), git-remote(1), git-branch(1), git-push(1), git-pull(1), git-unpushed(1), git-unpulled(1)


title: SYNOPSIS
content:
git mktag < <tag-object-content><br><i>Note: The tag object content is provided via standard input.</i>


title: DESCRIPTION
content:
<b>git-mktag</b> is a low-level "plumbing" command in Git, not typically used directly by end-users. Its primary function is to create a tag object from a provided textual representation of its content. It reads this canonical tag object content from standard input and then writes the resulting tag object's SHA-1 hash (object ID) to standard output.<br><br>This command is an internal helper used by higher-level "porcelain" commands like <b>git tag</b> to materialize tag objects within the Git repository's object database. It ensures the content is valid and then stores the tag object, which links a tag name to a specific commit or other Git object, along with metadata like the tagger's information and a tag message. It serves as the fundamental mechanism for creating durable tag objects in the Git object store.


title: CAVEATS
content:
This is a plumbing command. It is not designed for direct user interaction and should generally only be invoked by other Git commands or scripts that understand the precise format of Git tag objects. Incorrect input will likely result in an error or a malformed tag object. Users should typically use the higher-level <b>git tag</b> command for creating tags.


title: INPUT FORMAT FOR GIT-MKTAG
content:
The standard input for <b>git-mktag</b> must be a correctly formatted tag object. A typical tag object content looks like this:<br>object <i>&lt;object_sha1&gt;</i><br>type <i>&lt;object_type&gt;</i><br>tag <i>&lt;tag_name&gt;</i><br>tagger <i>&lt;tagger_name&gt; &lt;tagger_email&gt; &lt;timestamp&gt; &lt;timezone&gt;</i><br><br><i>&lt;tag_message&gt;</i><br><br>For example:<br>object 0df3b1c6d8e7a9b0c1d2e3f4a5b6c7d8e9f0a1b2<br>type commit<br>tag v1.0<br>tagger John Doe &lt;john.doe@example.com&gt; 1678886400 +0000<br><br>Version 1.0 Release<br>The blank line after the tagger line and before the tag message is crucial.


title: PARAMETERS
content:
<b><b>-z</b> | <b>--zero-terminate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that the input lines from standard input are null-terminated instead of newline-terminated. This is useful for processing filenames that may contain newlines.<br><br><b><b>--missing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the creation of a tree object even if some of the specified object IDs (blobs or subtrees) do not yet exist in the object database. This is useful in workflows where objects might be created later in a pipeline.<br><br><b><b>--batch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables batch mode, allowing multiple tree creation requests to be processed in a single invocation. Each request is terminated by a blank line or a null character if <b>-z</b> is used. The command prints the object ID for each created tree.<br><br><b><b>--batch-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>--batch</b>, this option ensures that all referenced objects (blobs, trees) exist in the object database before creating the tree. This is the default behavior in batch mode if neither <b>--batch-check</b> nor <b>--no-batch-check</b> is specified.<br><br><b><b>--no-batch-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>--batch</b>, this option disables the check for existence of referenced objects. Similar to the behavior of <b>--missing</b> but applies to batch mode.<br><br>


title: DESCRIPTION
content:
<b>git-mktree</b> is a low-level <I>"plumbing"</I> command within Git, designed to create a new tree object in the Git object database. It reads lines from its standard input, with each line describing an entry (file or subdirectory) to be included in the new tree. Each line must follow a strict format: <I>mode type object-id name</I>. This command does not interact with the Git working directory or index directly; its sole purpose is to programmatically construct a tree object based on the provided specifications.<br><br>Upon successful creation, <b>git-mktree</b> prints the SHA-1 hash (or other configured object ID) of the newly formed tree object to standard output. It is a fundamental building block for scripting and higher-level Git commands like <I>git commit-tree</I> that need to assemble specific tree structures without relying on the current state of the working directory or index. It's particularly useful for operations that involve constructing Git history or manipulating objects directly.


title: CAVEATS
content:
<b>git-mktree</b> is a plumbing command, meaning it's primarily intended for scripting and internal Git operations rather than direct end-user interaction. It expects highly specific input formatting, which can be prone to errors if not generated correctly.<br><br>The command does not create any actual files in the working directory; it only creates the tree object in the Git object database. The object IDs provided in the input must generally refer to existing objects in the repository's object database, unless the <b>--missing</b> option is used.


title: INPUT FORMAT
content:
The command reads entries from standard input, with each line (or null-terminated string) representing an entry for the new tree. The format for each line is:<br><br><I>&lt;mode&gt; &lt;type&gt; &lt;object-id&gt;&lt;TAB&gt;&lt;name&gt;</I><br><br>Where:<br><ul><li><I>&lt;mode&gt;</I>: The file mode (e.g., <I>100644</I> for a regular file, <I>100755</I> for executable, <I>120000</I> for a symbolic link, <I>040000</I> for a subdirectory).</li><li><I>&lt;type&gt;</I>: The type of Git object (<I>blob</I> for a file, <I>tree</I> for a subdirectory, <I>commit</I> for a submodule/gitlink).</li><li><I>&lt;object-id&gt;</I>: The SHA-1 hash (or other object ID) of the corresponding blob or tree object.</li><li><I>&lt;name&gt;</I>: The name of the file or subdirectory within the new tree.</li></ul><br>Fields are separated by a space, except for the last field (name) which is separated from the object-id by a TAB character. For example: <I>100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 README.md</I>


title: OUTPUT
content:
Upon successful creation of the tree object, <b>git-mktree</b> prints the SHA-1 hash (or other configured object ID) of the newly created tree object to standard output, followed by a newline character. In <b>--batch</b> mode, it prints the ID for each tree created.


title: SYNOPSIS
content:
<b>git mr</b> <I>command</I> [<I>args</I>]<br><br><b>git mr list</b> [<I>remote</I>]<br><b>git mr checkout</b> <I>MR_ID</I><br><b>git mr create</b> [options]<br><b>git mr show</b> <I>MR_ID</I><br><b>git mr open</b> <I>MR_ID</I><br><b>git mr delete</b> <I>MR_ID</I><br><b>git mr browse</b> <I>MR_ID</I><br><b>git mr help</b>


title: PARAMETERS
content:
<b><b>list</b> [<I>remote</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists open merge requests. If <I>remote</I> is specified, it lists MRs for that specific remote.<br><br><b><b>checkout</b> <I>MR_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks out the source branch of the specified merge request locally, making it ready for review or further development.<br><br><b><b>create</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates the creation of a new merge request. Various options are available to customize its properties.<br><br><b><i>create</i> <b>-t</b> <I>title</I>, <b>--title</b> <I>title</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the title for the new merge request. Defaults to the first commit message if not provided.<br><br><b><i>create</i> <b>-d</b> <I>description</I>, <b>--description</b> <I>description</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the detailed description for the new merge request.<br><br><b><i>create</i> <b>-s</b> <I>source_branch</I>, <b>--source</b> <I>source_branch</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the source branch for the merge request. Defaults to your current local branch.<br><br><b><i>create</i> <b>-T</b> <I>target_branch</I>, <b>--target</b> <I>target_branch</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target branch for the merge request. Defaults to the default branch of the remote.<br><br><b><i>create</i> <b>-M</b>, <b>--squash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the squash commits option for the new merge request, allowing commits to be squashed upon merging.<br><br><b><i>create</i> <b>-w</b>, <b>--wip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the new merge request as a Work-in-Progress (Draft), preventing accidental merges.<br><br><b><i>create</i> <b>-a</b>, <b>--assignee</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns the new merge request to yourself (the current authenticated user).<br><br><b><i>create</i> <b>-i</b> <I>issue_id</I>, <b>--issue</b> <I>issue_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Associates the new merge request with a specific issue by its ID.<br><br><b><i>create</i> <b>-r</b> <I>reviewer</I>, <b>--reviewer</b> <I>reviewer</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a reviewer to the new merge request by their GitLab username.<br><br><b><i>create</i> <b>-c</b> <I>CI_CONFIG</I>, <b>--ci-config</b> <I>CI_CONFIG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom CI configuration path for the new merge request.<br><br><b><i>create</i> <b>-f</b> <I>file</I>, <b>--file</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the title and description for the new merge request from the specified file.<br><br><b><b>show</b> <I>MR_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific merge request, including its status, source, and target branches.<br><br><b><b>open</b> <I>MR_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified merge request in your default web browser, navigating directly to its GitLab page.<br><br><b><b>delete</b> <I>MR_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a specific merge request. Use with caution as this action is typically irreversible.<br><br><b><b>browse</b> <I>MR_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for the <b>open</b> subcommand, providing an alternative way to open the MR in a browser.<br><br><b><b>help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help information for <b>git-mr</b> or detailed help for a specific subcommand.<br><br>


title: DESCRIPTION
content:
<b>git-mr</b> is a powerful Git subcommand designed to streamline interaction with GitLab Merge Requests directly from the command line. It eliminates the need to navigate the GitLab web interface for common merge request operations. Users can effortlessly list open merge requests, check out a merge request's branch for local review, create new merge requests, or open an existing merge request in the browser. This tool integrates seamlessly into existing Git workflows, making development faster and more efficient, especially for teams heavily reliant on GitLab for code collaboration and review. It leverages GitLab's API to fetch and submit merge request information, providing a comprehensive command-line interface for managing the merge request lifecycle.


title: CAVEATS
content:
This command is not a standard Git utility and requires separate installation, typically as a Python script. It relies on a configured GitLab API token (personal access token) for authentication and interaction with GitLab instances. Functionality is specific to GitLab Merge Requests and does not directly support GitHub Pull Requests or other Git hosting platforms. Ensure proper configuration of your GitLab remote URL and API token in your Git repository or environment variables for the tool to function correctly.


title: INSTALLATION AND CONFIGURATION
content:
To use <b>git-mr</b>, you typically need to install it, often via <b>pip</b> if using the Python version (e.g., <br><b>pip install git-mr</b>).<br><br>Configuration involves setting up your GitLab API token and the GitLab instance URL. This can be done via Git configuration (e.g., <br><b>git config --global gitlab.token your_token</b> <br>and <br><b>git config --global gitlab.url https://gitlab.com</b>)<br>or through environment variables. Ensure the remote associated with your GitLab project is correctly configured in your Git repository.


title: HISTORY
content:
The <b>git-mr</b> command, particularly the widely used Python-based implementation by Andrew Dunn, originated to bridge a gap in command-line interactions with GitLab's Merge Request system. Inspired by similar tools for GitHub, it aimed to provide developers with a native Git subcommand for common MR workflows, thereby reducing reliance on the web interface. Since its inception, it has been maintained as an open-source project, with contributions from the community enhancing its features and robustness over time, making it a popular choice for GitLab users who prefer terminal-centric development.


title: SYNOPSIS
content:
<b>git mv</b> [&lt;options&gt;] &lt;source&gt; &lt;destination&gt;<br><b>git mv</b> [&lt;options&gt;] &lt;source&gt; ... &lt;directory&gt;


title: PARAMETERS
content:
<b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the move or rename, even if the destination path exists and is different from the source. This will overwrite the existing destination file.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip moving or renaming a file if its destination already exists and is different from the source. The command will proceed with other files if multiple sources are specified.<br><br><b><b>-n</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a "dry run"; show what would happen without actually moving or renaming any files or modifying the Git index.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report the names of files as they are moved or renamed, providing more detailed output.<br><br><b><b>--cached</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only move/rename files in the index, not in the working directory. This is useful for correcting an erroneous `git add` of a renamed file without touching the disk.<br><br><b><i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the file or directory to be moved or renamed. Multiple sources can be specified when moving into a directory.<br><br><b><i>&lt;destination&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The new path for the file or directory, or the target directory if multiple sources are specified. If a directory, it must already exist.<br><br>


title: DESCRIPTION
content:
The <b>git-mv</b> command is used to move or rename files and directories within a Git repository, automatically updating the Git index to reflect these changes. It effectively performs the actions of a traditional <i>mv</i> command, followed by a <i>git rm</i> of the old path and a <i>git add</i> of the new path. This ensures that Git tracks the file's history across its new name or location.<br><br>Unlike simply using the shell's <i>mv</i> command, <b>git-mv</b> stages the move operation immediately, marking the file's old path for deletion and its new path for addition. This streamlined process saves manual steps and prevents potential issues with Git losing track of file history. It is particularly useful for maintaining an accurate and consistent repository state when reorganizing project structure.<br><br>The command is designed to work with files and directories that are already tracked by Git. After executing <b>git-mv</b>, the changes are staged and ready for a subsequent <i>git commit</i> to permanently record the move in the repository's history.


title: CAVEATS
content:
1. <b>Tracks Existing Files Only</b>: <b>git-mv</b> only operates on files and directories that are already tracked by Git (i.e., present in the index). Untracked files need to be handled manually.<br>2. <b>Immediate Staging</b>: The command stages the move operation immediately. This means the changes are ready for commit right after execution, but they are not committed until <i>git commit</i> is run.<br>3. <b>Destination Overwrites</b>: If the destination path already exists and is a tracked file, <b>git-mv</b> will overwrite it unless the <i>-k</i> option is used.<br>4. <b>Directory Handling</b>: When moving multiple sources into a directory, the destination directory must already exist. <b>git-mv</b> will not create new directories for you.


title: HOW GIT TRACKS RENAMES
content:
Git doesn't explicitly store rename events as distinct objects. Instead, when you use <b>git-mv</b>, it records a deletion of the old path and an addition of the new path in the index. During operations like <i>git log --follow</i> or <i>git diff</i>, Git uses a heuristic algorithm to detect file renames by comparing the content of files that were deleted in one commit and added in another. By using <b>git-mv</b>, you provide Git with a strong hint that a file was moved, making these rename detections more reliable and efficient.


title: HISTORY
content:
<b>git-mv</b> is a fundamental command in the Git version control system, designed to simplify file reorganization while preserving history. Its inclusion from early Git versions reflects the importance of tracking file renames and moves seamlessly. Before dedicated commands like <b>git-mv</b>, users had to manually perform a shell <i>mv</i>, followed by a <i>git rm</i> of the old path and a <i>git add</i> of the new path. <b>git-mv</b> automates this common pattern, making repository maintenance more efficient and less error-prone. It ensures that Git's rename detection heuristics can effectively link the old and new paths, thereby maintaining a coherent file history across commits.


title: PARAMETERS
content:
<b><b>&lt;committish&gt;</b>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more commit-ish objects (e.g., commit hash, branch name, tag name) for which to find symbolic names.<br><br><b><b>--tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only consider tags when trying to find a symbolic name for the revision. This can narrow down the search and provide more specific tag-based names.<br><br><b><b>--refs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only consider all refs (branches, remote-tracking branches, tags) when trying to find a symbolic name. This is generally the default behavior if neither <b>--tags</b> nor <b>--all</b> is specified.<br><br><b><b>--no-undefined</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not output 'undefined' when a name cannot be found for a given revision. Instead, the command will simply output the raw commit hash.<br><br><b><b>--always</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show 'undefined' if no name is found (this is the default behavior when <b>--no-undefined</b> is not used).<br><br><b><b>--abbrev</b>[=<I>n</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When no suitable symbolic name can be found, abbreviate the commit hash to <I>n</I> digits instead of its full length. If <I>n</I> is omitted, use the default abbreviation length.<br><br><b><b>--exclude</b>=<I>pattern</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not consider any refs that match the given shell <I>pattern</I> when searching for a symbolic name.<br><br>


title: DESCRIPTION
content:
The <i>git-name-rev</i> command helps translate raw Git commit hashes into human-readable, symbolic names. Given one or more commit-ish arguments (like a full SHA-1 hash, a short hash, or a branch name), it attempts to find the most appropriate symbolic name that refers to that commit. This typically involves finding the closest reachable tag, branch, or remote-tracking branch, and then indicating the distance from that reference (e.g., <br><i>main~3</i> or <i>v1.0.0-3-g123abc</i>).<br><br>This command is invaluable for making Git output more understandable, especially when dealing with commit IDs that are hard to remember or interpret. It's frequently used in scripts, debugging, and interactive sessions to provide context to specific points in a repository's history, making it easier to navigate and discuss.<br><br>By default, it tries to find the shortest possible name. If an exact match is not found, it finds the closest ancestor or descendant that has a name and calculates the distance, providing a concise and meaningful reference.


title: CAVEATS
content:
<i>git-name-rev</i> can be computationally intensive, especially in repositories with very deep histories or a large number of references, as it may need to traverse significant portions of the commit graph. The 'best' name it finds is determined by internal heuristics (e.g., preferring shorter names, exact matches, and current refs), which might not always align with a user's intuitive understanding for complex scenarios. It's primarily designed for human readability and may not be suitable for programmatic parsing where precise, machine-readable revision specifications are required.


title: OUTPUT FORMAT
content:
The output of <i>git-name-rev</i> for each given commit-ish is typically on a single line, formatted as:<br><i>&lt;commit-id&gt; SP (&lt;name&gt;)</i><br>where <i>&lt;commit-id&gt;</i> is the full 40-character SHA-1 hash of the commit, <i>SP</i> is a space, and <i>&lt;name&gt;</i> is the symbolic name found for the commit. If no name is found and <b>--no-undefined</b> is not used, <i>&lt;name&gt;</i> will be 'undefined'.


title: NAMING STRATEGY
content:
<i>git-name-rev</i> employs a strategy to find the 'best' symbolic name. It prioritizes exact matches (where a ref points directly to the commit). If no exact match exists, it then traverses the history to find the closest ancestor or descendant that has a name, indicating the distance using suffixes like <i>~N</i> (for ancestors) or <i>^N</i> (for Nth parent if multiple parents exist, though <i>~N</i> is more common for general ancestry). It generally prefers the shortest and most direct path to a named reference.


title: HISTORY
content:
<i>git-name-rev</i> is a foundational utility within Git, designed from early on to enhance the user experience by making repository history more accessible and understandable. While specific major development milestones aren't widely documented, its role has consistently been to bridge the gap between raw, cryptographic commit identifiers and meaningful, human-comprehensible labels. It evolved as part of Git's robust set of tools for navigating and and visualizing complex commit graphs, becoming indispensable for both interactive use and scripting efforts to contextualize revisions.


title: PARAMETERS
content:
<b><b>--ref</b> <I>ref</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the notes reference to operate on. This overrides the default notes ref configured via `notes.displayRef` or `notes.rewriteRef`. For example, `refs/notes/review`.<br><br><b><b>add</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a note to a given object. If no object is specified, it defaults to the current HEAD commit. Allows options for message source (file, stdin, message string) and behavior (overwrite, reuse).<br><br><b><b>show</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the notes for a given object. If no object is specified, it shows notes for HEAD.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all notes or notes for a specific object, displaying the object SHA-1 and the note SHA-1.<br><br><b><b>remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove notes for a given object or objects. Can take multiple objects as arguments or read from standard input.<br><br><b><b>copy</b> <I>from-object</I> <I>to-object</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy notes from one object to another. Useful for propagating notes when objects are rewritten.<br><br><b><b>append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append to the existing note for a given object. If no note exists, it creates one.<br><br><b><b>prune</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove notes that point to non-existent or unreachable objects, cleaning up the notes reference.<br><br><b><b>get-ref</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the currently active notes reference (e.g., `refs/notes/commits`).<br><br><b><b>merge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Merge notes from another branch or repository into the current notes ref. Supports various merge strategies (e.g., `union`, `ours`, `theirs`).<br><br><b><b>rewrite</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rewrite notes for objects that have been modified or rebased. This subcommand helps adjust notes to new object IDs after history rewriting operations.<br><br><b><b>pull</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch notes from a remote repository and merge them into the local notes ref.<br><br><b><b>push</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update notes on a remote repository from the local notes ref.<br><br>


title: DESCRIPTION
content:
The <b>git-notes</b> command allows users to attach arbitrary information, or 'notes', to any Git object, most commonly commits, without modifying the object's original SHA-1 hash. This mechanism provides a flexible way to add metadata, comments, or annotations that are separate from the immutable commit history. Notes are stored in special Git references, typically within the `refs/notes/` namespace (e.g., `refs/notes/commits`).<br><br>Because notes are themselves Git objects (blobs for content, commits for history), they can be pushed, pulled, and merged like other Git references. Unlike commit messages, notes are designed to be mutable and can be updated, copied, or removed without rewriting history, offering a dynamic layer of annotation. Common use cases include adding code review comments, bug tracking IDs, build information, or any arbitrary metadata that should not be embedded into the permanent commit record. Its decentralized nature allows different individuals or teams to maintain their own sets of notes, which can then be shared and merged.


title: CAVEATS
content:
Notes are stored in separate Git references (`refs/notes/*`) and are not part of the main commit object history. Consequently, they are not automatically pushed or pulled unless explicitly configured or specified during remote operations. Merging notes from different sources can lead to conflicts, similar to code merges, requiring manual resolution based on configured merge strategies. While notes offer flexibility for local annotations, relying on them for critical, globally shared metadata might be less robust than embedding information directly into commit messages or using tags, as notes can be easily pruned or modified independently. Additionally, notes are not cryptographically signed or verified in the same way commits are, meaning their authenticity isn't guaranteed by default.


title: NOTES NAMESPACE AND CONFIGURATION
content:
Notes are stored in a special hierarchy of references, typically under `refs/notes/`. By default, <b>git-notes</b> operates on `refs/notes/commits`. This default behavior can be customized via Git configuration options like `notes.displayRef` (for showing notes in `git log`) and `notes.rewriteRef` (for `git filter-branch` or `git rebase`). Different note namespaces can be created and used for distinct purposes, such as `refs/notes/review` for code review comments or `refs/notes/bugs` for bug tracking IDs, allowing for organizational flexibility.


title: DISPLAYING NOTES
content:
Notes can be seamlessly displayed alongside commit information when viewing repository history. The `git log` command supports the `--show-notes` option to include notes in its output. Additionally, configuring `notes.displayRef` in your Git configuration ensures that notes from a specified ref are automatically displayed when running `git log` without needing explicit options, making annotations readily visible during history review.


title: HISTORY
content:
The <b>git-notes</b> functionality was introduced in Git around version 1.6.0 (late 2008). Its primary motivation was to provide a flexible and non-destructive way to attach mutable metadata to immutable Git objects (like commits) without altering their SHA-1 checksums. This was a significant advancement over previous methods, which either required rewriting history (e.g., via `git filter-branch`) or embedding transient data directly into commit messages. Over time, its capabilities expanded with subcommands like `merge`, `pull`, and `push`, facilitating collaborative usage and management of notes across distributed repositories. Although not as widely adopted as commit messages or tags, <b>git-notes</b> remains a powerful tool for specific annotation and metadata management use cases, especially where altering the original commit history is undesirable.


title: SYNOPSIS
content:
<b>git obliterate</b> [<I>options</I>] &lt;pathspec&gt;...<br><b>git obliterate</b> [<I>options</I>] <b>--regexp</b> &lt;pattern&gt;...


title: PARAMETERS
content:
<b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show verbose output during the obliteration process.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run without making any actual changes to the repository.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass confirmation prompts before modifying the repository history.<br><br><b><b>--regexp</b> &lt;pattern&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret the provided pathspecs as regular expressions for matching files/directories.<br><br><b><b>--invert-regexp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invert the match for regular expressions, obliterating everything <i>except</i> what matches the pattern.<br><br><b><b>--index</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include items that currently exist only in the Git index (staging area).<br><br><b><b>--add-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add all untracked files to the index before processing, effectively including them in the history scan.<br><br><b><b>--pack-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;After rewriting history, pack all Git objects into a single pack file to optimize repository size.<br><br><b><b>--prune</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately prune unreferenced Git objects from the repository after rewriting history.<br><br><b><b>--no-gc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not run <i>git gc</i> (garbage collection) automatically at the end of the process.<br><br><b><b>--git-dir</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the <i>.git</i> directory if it's not in the current working directory.<br><br><b><b>--work-tree</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the working tree if it's not the current working directory.<br><br><b>&lt;pathspec&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files or directories to be obliterated from the repository history.<br><br>


title: DESCRIPTION
content:
<i>git-obliterate</i> is a powerful, non-standard Python script designed for the extreme task of irreversibly removing specified data (files, blobs, directories, etc.) from a Git repository's entire history. Unlike <i>git filter-branch</i> or tools like BFG Repo-Cleaner, <i>git-obliterate</i> aims for maximum obliteration, tracking content across renames and moves, and ensuring all references to the targeted data are purged from every commit, tree, and blob object. This makes it suitable for situations where sensitive or unwanted data must be completely erased from a repository, such as leaked credentials or large files. However, its destructive nature means it must be used with extreme caution and <b>only</b> on a cloned repository, as it rewrites history significantly. After obliteration, all collaborators must re-clone the repository.


title: CAVEATS
content:
<i>git-obliterate</i> is an extremely destructive tool that irreversibly rewrites a repository's history. It must be used with utmost caution, preferably on a fresh clone or a backup of the repository. All collaborators <b>must</b> discard their existing local repositories and re-clone after the obliteration process. It is a non-standard script and requires separate installation. It does not affect data that might be cached by remote hosting services (e.g., GitHub pull request caches).


title: INSTALLATION
content:
<i>git-obliterate</i> is not bundled with Git. It typically needs to be downloaded as a standalone Python script (e.g., from its GitHub repository) and placed in a directory that is included in your system's PATH, or executed directly using <i>python git-obliterate.py</i>.


title: USAGE BEST PRACTICES
content:
Always make a full backup or work on a fresh clone of the repository before running <i>git-obliterate</i>. Use the <b>--dry-run</b> option extensively to preview changes. Communicate clearly with all repository collaborators, as they will need to re-clone the repository from scratch after the history rewrite.


title: HISTORY
content:
<i>git-obliterate</i> is a non-standard utility, typically implemented as a Python script, developed by Jonathon D. Smith. It emerged as a more aggressive and thorough alternative to standard Git tools like <i>git filter-branch</i> for scenarios demanding the complete and irreversible eradication of specific content from a Git repository's history. Its design focuses on deep content tracking, even across renames and moves, ensuring that all references to targeted data are purged from every Git object. It gained attention for its ability to handle complex history rewriting tasks that other tools might miss, particularly when dealing with sensitive data leaks or large, unwanted files.


title: SYNOPSIS
content:
<b>git pack-objects</b> [<i>&lt;options&gt;</i>] <i>&lt;directory&gt;</i><br><b>git pack-objects</b> [<i>&lt;options&gt;</i>] <b>--stdout</b>


title: PARAMETERS
content:
<b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pack all objects found in the repository that are not yet packed.<br><br><b><b>--honor-prerequisites</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Consult the <b>pack.honorPrerequisites</b> configuration setting to determine if pack prerequisites should be considered, meaning objects that the remote side is known to have already.<br><br><b><b>--non-empty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only create a pack file if it contains at least one object.<br><br><b><b>--local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only pack objects that are considered local (not already packed in other packs present in the repository).<br><br><b><b>--stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the pack file to standard output instead of creating a file in the specified directory. When used, the index file is typically not written unless <b>--indexed-objects</b> is also used.<br><br><b><b>--indexed-objects</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When reading from stdin, assume objects are already indexed in an existing pack file. Primarily for internal optimization during certain Git operations.<br><br><b><b>--delta-base-offset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Store delta base addresses as offsets from the delta itself instead of object ID references. This is the default format for new packs.<br><br><b><b>--threads=&lt;n&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of threads to use for delta compression. A value of 0 uses the number of available CPU cores.<br><br><b><b>--shallow</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only pack objects that are part of a shallow clone, omitting history beyond the shallow boundary.<br><br><b><b>--unpacked</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only pack objects that are not already present in an existing pack file. Similar to <b>--local</b>.<br><br><b><b>--window=&lt;n&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum number of objects to look at as candidates for delta compression. A larger window finds better deltas but uses more memory and CPU. Defaults to 10.<br><br><b><b>--depth=&lt;n&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum depth of the delta chain. A deeper chain can save more space but requires more computation to decompress. Defaults to 50.<br><br><b><b>--no-reuse-delta</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to reuse existing delta chains from other packs during the packing process, even if they would be efficient.<br><br><b><b>--no-reuse-object</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to reuse existing objects from other packs when creating a new pack. This means the object will be duplicated if it's already in another pack.<br><br><b><b>--max-pack-size=&lt;n&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Break the pack file into multiple pack files if the total size of objects exceeds this limit (in bytes).<br><br><b><b>--progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show progress indications on standard error while packing.<br><br><b><b>--no-progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show progress indications.<br><br><b><b>--incremental</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize for incremental packing, meaning fewer objects are processed to find deltas, assuming the input objects are mostly new and the repository already has existing packs.<br><br><b><b>--thin</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a 'thin pack', which omits objects that are expected to be present on the receiving side of a fetch or push operation. This reduces network transfer size.<br><br><b><b>--with-ref-info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include reference information in the pack header, which can be used by the receiving side for transfer optimization.<br><br>


title: DESCRIPTION
content:
<i>git-pack-objects</i> is an internal Git plumbing command responsible for creating highly efficient pack files and their corresponding index files. It reads a list of object IDs from standard input, resolves them, and then writes a single pack file and its associated index file. Pack files optimize storage by delta-compressing objects that are similar, significantly reducing disk space and improving transfer efficiency, especially for large repositories. This command is typically invoked by other Git commands that need to bundle objects for storage or transmission, such as <b>git gc</b> (garbage collection) or <b>git upload-pack</b> (server-side sending of objects during a fetch or clone operation). It is not generally intended for direct user interaction.


title: CAVEATS
content:
This is a low-level "plumbing" command and is generally not intended for direct use by end-users. It is primarily invoked by other Git commands like <b>git gc</b>, <b>git upload-pack</b>, and <b>git receive-pack</b>. Misuse can lead to repository corruption or unexpected behavior. It expects object IDs to be fed into its standard input.


title: PLUMBING COMMAND
content:
<i>git-pack-objects</i> is categorized as a "plumbing" command within Git. This means it's a low-level command designed to be used by other Git commands or automated scripts, rather than directly by typical end-users. It operates directly on Git's core data structures, such as objects and pack files, providing fundamental building blocks for higher-level operations.


title: PACK FILES
content:
Pack files (typically ending with <i>.pack</i>) are Git's highly optimized storage format for objects. They consolidate multiple Git objects (like commits, trees, blobs, and tags) into a single file, predominantly using delta compression. Delta compression stores only the differences between similar objects, saving significant disk space and improving transfer efficiency. Each pack file is accompanied by an index file (<i>.idx</i>) that allows Git to quickly locate and retrieve any object within the pack.


title: HISTORY
content:
<i>git-pack-objects</i> is a foundational component of Git's object storage model, existing since the early stages of Git's development (circa 2005-2006). Its core function of delta-compression and efficient packing has been crucial for Git's performance and distributed nature. It has undergone continuous development, with enhancements like multithreading, improved delta algorithms, and specialized packing modes (e.g., thin packs, incremental packs) being added over time to optimize for various repository sizes and network conditions.


title: PARAMETERS
content:
<b><I>pack-file</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to Git packfiles (e.g., <i>.git/objects/pack/pack-abcdef.pack</i>) to be checked for redundancy. If this argument is omitted, <b>git-pack-redundant</b> will examine all packfiles present in the repository's object database (typically located in the <i>.git/objects/pack/</i> directory) to find those that are redundant relative to each other.<br><br>


title: DESCRIPTION
content:
The <b>git-pack-redundant</b> command is a Git <i>plumbing</i> utility designed to find and report packfiles whose objects are entirely contained within other packfiles. A packfile is considered redundant if every single object it contains is also present in one or more other packfiles specified in the input, or within the repository's entire object database if no specific packfiles are listed.<br><br>This command is vital for the efficient maintenance and cleanup of a Git repository's object database. It helps in identifying and marking obsolete or duplicate packfiles that may accumulate over time due to operations like fetches, pushes, or repository repacks. For instance, commands such as <b>git repack -d</b> leverage <b>git-pack-redundant</b> internally to safely remove old packfiles after a new, optimized pack has been created and verified. The output consists of a list of filenames of the identified redundant packfiles, one per line.


title: CAVEATS
content:
<b>git-pack-redundant</b> strictly identifies packfiles that are <i>entirely</i> redundant. If a packfile contains even a single object that is not present in any other packfile under consideration, it will not be reported as redundant.<br><br>Due to the nature of its operation, this command can be computationally intensive for repositories with a very large number of packfiles, as it needs to open and analyze their respective index files (<i>.idx</i>) to determine object containment. It is primarily an internal Git command, not typically run directly by end-users.


title: OUTPUT FORMAT
content:
The command outputs the full paths and filenames of the identified redundant packfiles, with each filename on a new line, to standard output. This output can be piped to other commands for automated deletion or processing.


title: MAINTENANCE INTEGRATION
content:
While runnable manually, <b>git-pack-redundant</b>'s primary role is within Git's automated maintenance scripts and other commands. For example, after running <b>git repack -ad</b>, the command is used to safely identify and remove the old packfiles whose objects have been moved into the newly created, optimized pack.


title: HISTORY
content:
As a fundamental <i>plumbing</i> command, <b>git-pack-redundant</b> has been an integral part of Git's object database management since the early stages of its development. Its purpose is to support robust and efficient repository maintenance, particularly in the automated cleanup of obsolete packfiles that result from operations consolidating or optimizing the object store. Its focus remains on providing a precise mechanism for identifying completely covered packfiles, contributing to the overall compactness and performance of Git repositories.


title: PARAMETERS
content:
<b><I>--all</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pack all refs found in <i>refs/</i>, including those under <i>refs/remotes/</i> and <i>refs/stash/</i>. By default, only <i>refs/heads/</i>, <i>refs/tags/</i>, and <i>refs/notes/</i> are packed.<br><br><b><I>--prune</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;After successfully packing loose refs, remove the original loose ref files. This is crucial for actual disk space saving and reduction of the number of files in the repository.<br><br>


title: DESCRIPTION
content:
<i>git-pack-refs</i> is a Git plumbing command designed to optimize the storage of references (like branches, tags, and notes). Git stores references either as individual files (loose refs) in the <i>.git/refs/</i> directory hierarchy or as entries within a single, optimized file called <i>.git/packed-refs</i>. This command converts loose references into this packed format. Packing references significantly improves performance for operations that involve iterating over many references, such as listing all branches or tags, by reducing the number of files Git needs to open and read. It also conserves disk space by consolidating many small files into one. While new references or updates to existing ones are initially created as loose refs, <i>git-pack-refs</i> can be run manually or, more commonly, is invoked automatically as part of <i>git gc</i> (garbage collection) to keep the repository efficient.


title: CAVEATS
content:
This command is primarily an internal Git plumbing command, usually invoked automatically by <i>git gc</i>. Manual execution is generally not required unless specific repository optimization or debugging is needed.<br>New loose refs will always be created upon ref updates (e.g., <i>git branch</i>, <i>git update-ref</i>), even if a packed ref for that name already exists. <i>git pack-refs</i> must be run again (with <i>--prune</i>) to consolidate and clean up these new loose refs.


title: HOW PACKED REFS WORK
content:
When <i>git-pack-refs</i> runs, it creates or updates the <i>.git/packed-refs</i> file. This file stores references in a sorted list, with each line containing the SHA-1 or SHA-256 object name followed by the reference name. When Git looks up a reference, it first checks for a loose ref file (e.g., <i>.git/refs/heads/master</i>). If a loose ref exists, it takes precedence. If not, Git then consults the <i>.git/packed-refs</i> file for the reference.


title: HISTORY
content:
The concept of packing references is fundamental to Git's scalability and efficiency, particularly for repositories with a large number of branches and tags. It was introduced early in Git's development to optimize performance and disk usage by consolidating numerous small ref files into a single, quickly readable file. It remains a core component of Git's internal maintenance routines, primarily managed via the <i>git gc</i> command.


title: PARAMETERS
content:
<b><i>&lt;url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The remote repository URL to be parsed. This can be in various Git-supported formats, including SSH SCP-like syntax (e.g., <i>user@host:path/to/repo.git</i>), HTTP/HTTPS URLs, Git protocol URLs, or local file paths.<br><br>


title: DESCRIPTION
content:
<b>git-parse-remote</b> is an <i>internal plumbing command</i> within Git, not intended for direct invocation by end-users.<br>Its primary purpose is to parse and normalize Git remote URLs, extracting components such as the scheme (e.g., <i>ssh</i>, <i>http</i>, <i>https</i>, <i>git</i>, <i>file</i>), hostname, port, username, and repository path.<br>Other Git commands, like <b>git clone</b>, <b>git remote add</b>, and <b>git fetch</b>, utilize this helper to consistently interpret remote locations, handling various URL formats (SCP-like, full URLs, local paths) and ensuring correct communication with remote repositories.<br>It acts as a foundational utility for Git's remote operations.


title: CAVEATS
content:
This is an <i>internal plumbing command</i>. It is not designed for direct user interaction and its behavior, interface, or output format may change without notice across Git versions.<br>It may not be present in the user's PATH as a directly executable command on all Git installations, as it's typically invoked by other Git scripts or built-in commands.


title: OUTPUT FORMAT
content:
When executed internally by Git, <b>git-parse-remote</b> typically prints the parsed components of the URL to standard output in a key-value pair format.<br>For example, for a URL like <i>ssh://git@github.com/git/git.git</i>, it might output:<br><i>scheme=ssh</i><br><i>user=git</i><br><i>host=github.com</i><br><i>path=/git/git.git</i><br>The exact set of keys and their order may vary based on the URL type and Git version.


title: HISTORY
content:
<b>git-parse-remote</b> has been an integral part of Git's internal architecture, evolving with Git's growing sophistication in handling various remote protocols and URL formats.<br>As Git gained support for more transport methods and refined its parsing logic for URLs, this internal helper matured to provide a consistent and robust mechanism for interpreting remote addresses across different Git commands.<br>Its existence underscores Git's modular design, where complex tasks are broken down into specialized internal utilities.


title: PARAMETERS
content:
<b>-d, --description &lt;text&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a descriptive title or comment for the shared paste.<br><br><b>-l, --language &lt;lang&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the programming language for syntax highlighting, e.g., 'python' or 'javascript'.<br><br><b>-p, --public</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the created paste publicly accessible on the service.<br><br><b>-s, --secret, --private</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the created paste private or secret, accessible only via its unique URL.<br><br><b>-f, --filename &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a specific filename to the content, especially useful when reading from standard input.<br><br><b>-u, --url-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs only the URL of the created paste to standard output.<br><br><b>-c, --copy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies the URL of the created paste to the system clipboard.<br><br><b>--no-browser</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the command from automatically opening the paste's URL in a web browser.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>git-paste</b> utility.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message and exits.<br><br>


title: DESCRIPTION
content:
<b>git-paste</b> is a utility designed to streamline the process of sharing text, code snippets, or command output through Git-backed services, most commonly GitHub Gist. Instead of manually navigating web interfaces, users can pipe content directly into <b>git-paste</b> or specify a file. The command authenticates using existing Git credentials (e.g., SSH keys or personal access tokens) and then uploads the content, optionally with syntax highlighting based on file extension or explicit language declaration, and a specified description.<br><br>Upon successful upload, <b>git-paste</b> typically provides a URL to the newly created paste, enabling quick and easy sharing. This tool leverages the version control capabilities of Git to offer a persistent and organized way to share temporary information.


title: CAVEATS
content:
<ul><li><i>Implementation Variability</i>: <b>git-paste</b> is not a standard Git command, and its exact functionality, options, and underlying service support can vary significantly between different community-contributed implementations.</li><li><i>Authentication</i>: It relies on correctly configured Git credentials (e.g., personal access tokens or SSH keys) for the target service (e.g., GitHub) to upload content.</li><li><i>Service Specificity</i>: Most prevalent versions are tailored for GitHub Gists, meaning they might not directly support other pastebin services without modification.</li><li><i>Security</i>: Users should be cautious when pasting sensitive information, especially if the paste is made public.</li></ul>


title: AUTHENTICATION DETAILS
content:
<code>git-paste</code> typically relies on your existing Git configuration for authentication. For GitHub Gists, this means using either personal access tokens (PATs) configured with the necessary Gist scope or SSH keys registered with your GitHub account, which are used to interact with the Gist API or a private Git repository.


title: INPUT SOURCES
content:
By default, if no <i>file</i> argument is provided, <code>git-paste</code> reads its content from standard input (stdin). This allows users to pipe the output of other commands directly into the tool for sharing, such as <code>ls -l | git-paste</code>.


title: SYNTAX HIGHLIGHTING INFERENCE
content:
Many implementations attempt to automatically determine the language for syntax highlighting. If a <i>file</i> is provided, the language is often inferred from its file extension. When reading from stdin, the user might need to explicitly specify the language using the <code>--language</code> option.


title: HISTORY
content:
<b>git-paste</b> does not have an official release history as a standalone project. Instead, it emerged organically from the developer community's need for a quick, command-line way to share code snippets and console output, particularly leveraging services like GitHub Gist. Various independent scripts and tools have been developed over time, often named <b>git-paste</b>, <b>gist</b>, or similar, each offering slightly different features but sharing the core concept of piping content to a Git-backed paste service. Its development is driven by community contributions and specific user requirements rather than a centralized project.


title: SEE ALSO
content:
git(1): The distributed version control system that <b>git-paste</b> leverages., gist(1): A dedicated command-line tool for GitHub Gists, often serving a similar purpose., curl(1): A common tool used internally by <b>git-paste</b> for making HTTP requests to API endpoints.


title: PARAMETERS
content:
<b>--stable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Optional)</I> This option ensures the patch ID is computed using the "stable" algorithm. It has been the default behavior since Git version 2.12 and earlier, and the old, less stable algorithm is no longer available. Explicitly specifying it has no effect on modern Git versions but might be used for clarity or compatibility with very old scripts.<br><br>


title: DESCRIPTION
content:
<b>git-patch-id</b> reads a patch from standard input and generates two SHA1 hashes on standard output: a "patch ID" and a "subject ID". The "patch ID" is a stable identifier for the patch's content, computed from the diff after normalizing it (removing leading whitespace, line numbers from hunk headers, etc.). This ensures that minor changes like reformatting or shifting line numbers don't alter the ID. It's primarily used by <b>git-am</b> to detect if a patch has already been applied, preventing redundant application.<br><br>The "subject ID" is a SHA1 hash of the patch's subject line.


title: CAVEATS
content:
The <I>--stable</I> option is now the default and has no practical effect on modern Git versions (2.12+). The older, less stable patch ID algorithm is no longer supported. The patch ID is a heuristic for content comparison and should not be relied upon for cryptographic security.


title: HOW PATCH ID IS COMPUTED
content:
The patch ID is derived from the diff content itself. Git normalizes the diff by ignoring leading whitespace and stripping line numbers from hunk headers before hashing. This makes the ID resilient to common formatting variations in patches.


title: USE CASES
content:
Beyond <b>git-am</b>'s automatic detection, <b>git-patch-id</b> can be used manually by developers to check for duplicate patches in a series or to uniquely identify specific changes independent of their commit hash or authorship details.


title: HISTORY
content:
The <b>git-patch-id</b> command was introduced early in Git's history to help with patch management. Initially, it used an algorithm that could be sensitive to minor format changes. The more robust "stable" algorithm was introduced and eventually became the default around Git 2.12 (released in 2017). The old algorithm was then removed, making <I>--stable</I> a redundant, though harmless, flag.


title: PARAMETERS
content:
<b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists open pull requests in the current repository. Can be filtered by various options (e.g., user, state, base branch).<br><br><b><b>show</b> <I>PR_NUMBER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific pull request, including its status, title, description, and commits.<br><br><b><b>checkout</b> <I>PR_NUMBER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches the branch associated with the specified pull request and checks it out locally. This is useful for reviewing or testing changes.<br><br><b><b>create</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new pull request from your current local branch. You can specify the title and body of the pull request and choose the target base branch.<br><br><b><b>merge</b> <I>PR_NUMBER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to merge the specified pull request into the base branch. This typically performs a standard Git merge operation.<br><br><b><b>close</b> <I>PR_NUMBER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Closes the specified pull request on the remote hosting platform.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <I>git-pr</I> or a specific subcommand.<br><br><b><b>-t</b> <I>title</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>create</b> to specify the title of the new pull request.<br><br><b><b>-b</b> <I>body</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>create</b> to specify the body/description of the new pull request. Can accept multi-line input.<br><br><b><b>--head</b> <I>branch</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>create</b> to explicitly specify the head branch (your feature branch) for the pull request, if different from the current branch.<br><br><b><b>--base</b> <I>branch</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>create</b> to explicitly specify the base branch (target branch like <I>main</I> or <I>develop</I>) for the pull request.<br><br>


title: DESCRIPTION
content:
The <I>git-pr</I> command is an external Git extension designed to streamline the management of pull requests directly from the command line. It acts as a powerful interface between your local Git repository and remote hosting platforms like GitHub, enabling you to perform common pull request operations without leaving your terminal. <br><br>With <I>git-pr</I>, developers can easily list active pull requests, view their details, checkout a pull request's branch for local testing or review, create new pull requests from current branches, and even merge or close existing ones. This tool significantly enhances the developer workflow by integrating pull request management into the familiar Git command-line environment, reducing context switching and improving efficiency.


title: CAVEATS
content:
The <I>git-pr</I> command is typically an external script or utility, not a built-in Git command. Its availability and specific functionalities depend on its installation and configuration, often involving cloning a repository and adding the script to your PATH. It relies on a remote hosting service's API (e.g., GitHub's API) and usually requires authentication (e.g., via personal access tokens or SSH keys) to perform operations. Ensure it is correctly installed and configured in your system's PATH and that you have the necessary API credentials set up.


title: DEPENDENCIES
content:
The <I>git-pr</I> script often relies on standard shell utilities like <I>curl</I> for API communication and <I>jq</I> for JSON parsing. Ensure these are installed on your system for full functionality. Network connectivity to the remote Git hosting service is also required.


title: CONFIGURATION
content:
For interacting with services like GitHub, <I>git-pr</I> may read authentication tokens from environment variables (e.g., <I>GITHUB_TOKEN</I>) or Git configuration. Specific setup instructions for API keys and host configurations can vary based on the particular <I>git-pr</I> implementation being used.


title: HISTORY
content:
The concept of extending Git to manage pull requests directly from the command line gained traction with the rise of distributed version control platforms like GitHub. Tools like <I>git-pr</I> emerged as early solutions to bridge the gap between the local Git workflow and remote pull request mechanisms. While specific origin dates for the popular <I>mislav/git-pr</I> script are in the early 2010s, its design principles influenced and were eventually superseded by more comprehensive, official CLI tools like GitHub CLI (<I>gh</I>) and <I>hub</I> (an earlier GitHub project), which offer broader repository and pull request management capabilities.


title: PARAMETERS
content:
<b>--expire=<time></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prunes objects older than the specified <time>. <br>This can be a relative date like '2 weeks ago', '1 day', or 'now' (or '0'). The default is '2 weeks ago', meaning objects less than two weeks old are not pruned. Using 'now' prunes all unreachable objects immediately, regardless of age.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports the objects that are being removed.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a 'dry run': shows what would be removed without actually deleting any objects.<br><br>


title: DESCRIPTION
content:
<i>git prune</i> is a low-level <B>plumbing</B> command that cleans up the object database by removing objects that are no longer reachable from any of your refs (branches, tags, HEAD, remote-tracking branches, etc.). These unreachable objects are often created during operations like rebasing, amending commits, or resetting, where original commits become unreferenced.<br><br>By default, <i>git prune</i> only removes objects that are older than two weeks, providing a safety margin. This command is typically invoked by <i>git gc</i> (garbage collection) to keep the repository tidy and efficient. Running <i>git prune</i> can help reduce the size of your repository, especially after operations that create many temporary or unreferenced objects. It's important to understand that <i>git prune</i> only removes <B>unreachable</B> objects; it will never remove objects that are part of your history, even if they are very old.


title: CAVEATS
content:
<i>git prune</i> only removes unreachable objects. It will not remove objects that are part of reachable history, even if they are very old or seem unnecessary.<br>By default, objects less than two weeks old are <B>not</B> pruned, providing a safety net. Use <i>--expire=now</i> (or <i>--expire=0</i>) to prune all unreachable objects immediately.<br>Once an object is pruned, it is permanently gone unless it exists in another repository or a backup. There is no 'undo' for <i>git prune</i>.<br>It's a 'plumbing' command; most users interact with <i>git gc</i> which calls <i>git prune</i> internally.


title: OBJECT REACHABILITY
content:
<i>git prune</i> operates on the concept of object reachability. An object is considered reachable if it can be found by traversing the commit graph starting from any ref (branches, tags, HEAD, remote-tracking branches, reflogs). Objects not reachable by this process are considered 'dangling' or 'unreachable' and are candidates for pruning.


title: PLUMBING COMMAND
content:
<i>git prune</i> is classified as a 'plumbing' command in Git. Plumbing commands are low-level commands designed to be used by other Git commands or by scripts, rather than directly by end-users. This distinguishes them from 'porcelain' commands (like <i>git add</i>, <i>git commit</i>, <i>git status</i>) which are user-friendly.


title: HISTORY
content:
<i>git prune</i> has been a fundamental part of Git's object management system since its early days. It's a core component of how Git maintains its repository efficiency by cleaning up unreachable objects. While users typically interact with <i>git gc</i> for repository maintenance, <i>git prune</i> serves as the underlying mechanism for removing these objects, demonstrating Git's modular design where complex operations are built upon simpler, focused tools. Its default 2-week expiry period has been a long-standing safety feature.


title: PARAMETERS
content:
<b>-n, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not actually prune, just show what would be pruned.<br>This is useful for previewing the effects of the command without making any changes to the repository.<br><br>


title: DESCRIPTION
content:
<i>git prune-packed</i> is a low-level "plumbing" command in Git used for repository maintenance. Its primary function is to remove loose objects from the <i>.git/objects</i> directory that are already contained within one or more <i>.pack</i> files. When Git packs objects, the original loose objects become redundant. While <i>git gc</i> (garbage collection) usually handles this, sometimes loose objects might remain after a <i>repack</i> operation or if <i>git gc</i> is not thorough enough. This command helps to reclaim disk space by identifying and deleting these unnecessary loose objects, ensuring that only the most efficient representation (packed objects) of the data is kept when possible. It's often run implicitly by other Git commands or scripts rather than directly by end-users.


title: CAVEATS
content:
This is a plumbing command; it's generally not invoked directly by end-users. Higher-level commands like <i>git gc</i> typically handle this pruning implicitly as part of a larger cleanup process.<br>It only removes loose objects that are <b>packed</b>. It does not prune unreachable loose objects that are <b>not</b> packed (that's <i>git prune</i>).<br>Care should be taken when using this command directly, although the <i>--dry-run</i> option provides a safe way to preview changes.


title: PURPOSE IN REPOSITORY MAINTENANCE
content:
While <i>git gc</i> is the primary command for repository maintenance, <i>git prune-packed</i> plays a specific role in ensuring that loose objects which have been successfully included in a pack file are removed. This prevents a repository from accumulating redundant loose objects, which could otherwise waste disk space.


title: PLUMBING COMMAND
content:
As a "plumbing" command, <i>git prune-packed</i> is designed to be used by other Git commands or scripts rather than directly by an end-user. This makes it a building block for more complex Git operations and maintenance scripts. Users typically interact with <i>git gc</i>, which orchestrates various pruning and packing operations, often including <i>git prune-packed</i> internally.


title: HISTORY
content:
The <i>git-prune-packed</i> command has been a part of Git since its early days, contributing to its robust object management system. It was designed to address the specific scenario of cleaning up loose objects that become redundant after they've been packed into a <i>.pack</i> file, ensuring efficient disk space usage and maintaining repository hygiene. Its plumbing nature reflects Git's modular design, where lower-level tasks are exposed for scripting and higher-level commands.


title: PARAMETERS
content:
<b><i><git-rebase-options></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any standard options typically accepted by <i>git rebase</i> (e.g., <i>-i</i>, <i>--onto</i>, <i><base></i>, <i><newbase></i>). These are usually passed directly to the underlying <i>git rebase</i> command, allowing the user to interactively "psychoanalyze" their history.<br><br>


title: DESCRIPTION
content:
<i>git-psykorebase</i> is a non-standard, humorous Git command, often implemented as a simple shell script or an April Fool's joke. It aims to playfully satirize the often complex and sometimes "traumatic" process of using <i>git rebase</i> by suggesting a "psychological evaluation" of your commit history.<br><br>While its actual implementation varies, it typically involves printing humorous messages related to commit trauma, therapy, or psychological analysis before potentially invoking the standard <i>git rebase -i</i> command to allow the user to interactively modify their history. It serves no technical purpose beyond entertainment and acts as a light-hearted commentary on the challenges of maintaining clean Git commit logs. Users should not expect it to perform any actual psychological operations on their repository.


title: CAVEATS
content:
<i>git-psykorebase</i> is purely for humor and educational commentary on Git workflows. It provides no functional improvement to Git itself and should not be relied upon for critical repository operations. Its actual behavior depends entirely on how it's implemented by individual users or pranksters; it might just print a joke message, or it might indeed call <i>git rebase -i</i>. Always understand the underlying <i>git rebase</i> command before using this or any similar wrapper.


title: USAGE CONTEXT
content:
This command is typically implemented as a standalone executable script (e.g., <i>git-psykorebase</i> placed in your PATH) that acts as a Git subcommand. When invoked, it often outputs satirical messages about your commits' mental state before performing a standard Git rebase operation. It's best used when you need a chuckle after a particularly frustrating rebase session.


title: HISTORY
content:
<i>git-psykorebase</i> doesn't have a formal development history or a specific creator. It emerged as a recurring joke and community script within the Git ecosystem, often seen around April Fool's Day or as a humorous take on the complexities of <i>git rebase</i>. Its purpose is primarily to lighten the mood around a powerful, but sometimes daunting, Git operation.


title: SYNOPSIS
content:
<b><I>git pull</I></b> [<I>options</I>] [<I>repository</I> [<I>refspec</I>...]]<br>Example: <b><I>git pull</I></b> <I>origin</I> <I>main</I><br>Example: <b><I>git pull</I></b> <I>--rebase</I><br>Example: <b><I>git pull</I></b>


title: PARAMETERS
content:
<b>--rebase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebase the current branch on top of the fetched branch instead of merging.<br><br><b>--no-rebase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the <I>pull.rebase</I> configuration, forcing a merge.<br><br><b>--ff-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refuse to merge if a fast-forward merge is not possible.<br><br><b>--no-ff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a merge commit even if a fast-forward merge is possible.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show what would be done without actually making any changes.<br><br><b>--tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch all tags from the remote (behaves like <I>git fetch --tags</I>).<br><br><b><repository></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the remote to pull from (e.g., <I>origin</I>). Defaults to the upstream remote configured for the current branch.<br><br><b><refspec></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which remote branch to fetch and merge/rebase (e.g., <I>main</I>). If omitted, it defaults to the upstream branch configured for the current local branch.<br><br>


title: DESCRIPTION
content:
The <b><I>git pull</I></b> command is a convenient way to bring changes from a remote repository into your current local branch. It is essentially a combination of two other commands: <b><I>git fetch</I></b> followed by <b><I>git merge</I></b>.<br><br>First, <b><I>git fetch</I></b> downloads commits, files, and refs from the specified remote repository into your local repository without modifying your working directory. These changes are stored in remote-tracking branches (e.g., <I>origin/main</I>).<br><br>Second, <b><I>git pull</I></b> then integrates those fetched changes. By default, it performs a <b><I>git merge</I></b> of the remote-tracking branch into your current local branch. If a fast-forward merge is possible (meaning your local branch has no unique commits since the last pull), Git will simply move your branch pointer forward. Otherwise, it will create a new merge commit.<br><br>Alternatively, you can configure <b><I>git pull</I></b> to perform a <b><I>git rebase</I></b> instead of a merge, which replays your local commits on top of the fetched changes, resulting in a linear history. This behavior can be controlled with the <b><I>--rebase</I></b> option or by setting the <I>pull.rebase</I> configuration.


title: CAVEATS
content:
<ul><li><b>Merge Conflicts:</b> If changes on the remote branch conflict with your local changes, <b><I>git pull</I></b> (when merging) will result in merge conflicts that you must resolve manually.</li><li><b>Rebase Implications:</b> Using <b><I>--rebase</I></b> rewrites commit history. While often preferred for a cleaner history, it should be used with caution on branches that others have already pulled, as it can cause issues for collaborators.</li><li><b>Detached HEAD:</b> Pulling on a detached HEAD will fetch, but not integrate, as there is no local branch to merge into.</li><li><b>Large Repositories:</b> In very large repositories, pulling can take significant time and consume network resources.</li></ul>


title: DEFAULT BEHAVIOR CONFIGURATION
content:
You can configure Git to automatically use <I>--rebase</I> for all pulls by setting <I>git config --global pull.rebase true</I>. This changes the default merge behavior.


title: DISTINCTION FROM `GIT FETCH`
content:
While <I>git pull</I> fetches and integrates, <I>git fetch</I> only downloads data from the remote without modifying your local working directory or current branch. This allows you to inspect remote changes before integrating them.


title: UPSTREAM BRANCH
content:
By default, <I>git pull</I> fetches from and merges/rebases with the remote-tracking branch that your current local branch is configured to track (its "upstream"). This is often set automatically when you <I>git clone</I> or <I>git branch --set-upstream-to</I>.


title: HISTORY
content:
The <b><I>git pull</I></b> command has been a fundamental part of Git since its early days, designed to simplify the common workflow of updating a local branch from its upstream counterpart. Initially, it was a simple wrapper script around <b><I>git fetch</I></b> and <b><I>git merge</I></b>. Over time, options like <b><I>--rebase</I></b> were added to accommodate different workflow preferences, allowing users to choose between a merge-based history (with merge commits) and a rebase-based linear history. Its widespread adoption reflects Git's philosophy of providing both atomic operations (fetch, merge, rebase) and convenience commands (pull) for common tasks.


title: SYNOPSIS
content:
<b>git pull-request</b> [-a] [-c <i>&lt;commit&gt;</i>] [<i>&lt;base&gt;</i>] [<i>&lt;head&gt;</i>] [--title <i>&lt;title&gt;</i>] [--body <i>&lt;body&gt;</i>] [--draft] [--no-edit] [--no-push] [--squash]


title: PARAMETERS
content:
<b><i>&lt;base&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target base branch for the pull request on the remote repository. Defaults to <i>master</i> or <i>main</i>.<br><br><b><i>&lt;head&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The source branch for the pull request. Defaults to the current branch. Can also be specified as <i>&lt;base&gt;</i>:<i>&lt;head&gt;</i>.<br><br><b>-t, --title <i>&lt;title&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly set the title of the pull request. Defaults to the subject line of the last commit.<br><br><b>-m, --body <i>&lt;body&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly set the body (description) of the pull request. Defaults to the full message of the last commit.<br><br><b>-d, --draft</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create the pull request as a draft, indicating it's still a work in progress.<br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Amend or update the last pull request created for the current branch.<br><br><b>-c <i>&lt;commit&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a pull request that proposes to cherry-pick a specific commit.<br><br><b>--no-edit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not open the configured editor for modifying the pull request title and body before submission.<br><br><b>--no-push</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not push the current branch to its upstream remote (e.g., <i>origin</i>) before creating the pull request.<br><br><b>--squash</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a flag to GitHub to suggest squashing commits when merging the pull request.<br><br>


title: DESCRIPTION
content:
The <b>git-pull-request</b> command, commonly provided by the <b>git-extras</b> package, streamlines the process of submitting changes for review on GitHub directly from your terminal. It's designed to automate many of the steps typically involved in creating a pull request through the web interface. By default, it intelligently infers the title from the subject line of your last commit and uses the full commit message as the body of the pull request.<br><br>Before attempting to create the pull request, it ensures your current branch is pushed to its configured upstream (usually <i>origin</i>). The command provides flexibility through various options, allowing you to specify a target base branch (e.g., <i>master</i> or <i>main</i>), explicitly define the pull request's title and body, and even mark it as a draft. After initial data population, it opens a text editor (as configured by <i>GIT_EDITOR</i> or <i>EDITOR</i>) to allow you to review and modify the pull request details before final submission. This integration helps maintain flow within the command line, reducing the need to switch contexts to a web browser for routine pull request creation.


title: CAVEATS
content:
This command is not part of core Git; it is typically provided by the <b>git-extras</b> collection of commands. It primarily interacts with GitHub and assumes GitHub as the remote host. It relies on proper GitHub authentication (e.g., SSH keys or credential helper) being set up. It does not natively support other Git hosting platforms (like GitLab or Bitbucket) without custom configuration or alternative tools.


title: DEFAULT BEHAVIOR
content:
By default, <b>git-pull-request</b> pushes the current branch to its configured upstream remote (usually <i>origin</i>) before creating the pull request. It infers the pull request title from the last commit's subject and the body from its message. It then opens a text editor for review and modification before final submission.


title: ENVIRONMENT VARIABLES
content:
The command respects the <i>GIT_EDITOR</i> or <i>EDITOR</i> environment variables to determine which text editor to use for reviewing and modifying the pull request details.


title: HISTORY
content:
The <b>git-pull-request</b> command is a key component of the <b>git-extras</b> project, a popular collection of community-contributed Git commands created by TJ Holowaychuk. It emerged as an effort to streamline and automate common GitHub interactions directly from the command line, integrating pull request creation seamlessly into the developer's terminal workflow. Its development focused on providing a quick and efficient way to submit changes for review without needing to switch to a web browser.


title: SYNOPSIS
content:
<b>git push</b> [<I>options</I>] [<I>repository</I> [<I>refspec</I>...]]<br><b>git push</b> <I>--dry-run</I> | <I>--porcelain</I>


title: PARAMETERS
content:
<b><I>repository</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The remote repository name to push to (e.g., <i>origin</i>). If omitted, the default remote for the current branch is used.<br><br><b><I>refspec</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies what to push from your local repository to the remote. Can be a branch name (e.g., <i>main</i>), or a detailed mapping like <i>local_ref:remote_ref</i>. Multiple refspecs can be provided.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the update even if the remote history has diverged (non-fast-forward update). <b>Use with extreme caution, as it can overwrite history on the remote!</b><br><br><b>--force-with-lease[=<ref>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A safer alternative to <b>--force</b>. It only forces the push if the remote branch has not been updated since the last fetch, preventing accidental overwrites by others.<br><br><b>-u, --set-upstream</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For every branch that is successfully pushed, add upstream (tracking) reference, used by argument-less <b>git pull</b> and other commands.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pushes all branches (i.e., all <i>refs/heads/</i> references) to the remote repository.<br><br><b>--tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pushes all local tags (i.e., all <i>refs/tags/</i> references) to the remote repository.<br><br><b>--dry-run, -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what would happen without actually pushing the changes. Useful for previewing potential updates.<br><br><b>--delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the specified remote branches or tags. The syntax is <i>:remote_branch_name</i> or <i>--delete remote_branch_name</i>.<br><br><b>--porcelain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces machine-readable output for programmatic parsing.<br><br>


title: DESCRIPTION
content:
<b>git push</b> is a fundamental Git command used to <i>upload local repository content to a remote repository</i>. It transfers committed changes from your local branches and tags to a specified remote, typically <i>origin</i>. When you execute <b>git push</b>, Git examines your local branches and their corresponding upstream branches on the remote. It then attempts to update the remote references, ensuring that all necessary objects (commits, trees, blobs) are also transferred.<br><br>The default behavior prevents "non-fast-forward" updates, meaning it will reject pushes if your local branch history has diverged from the remote's history, requiring you to first <b>git pull</b> to merge or rebase. Common uses include sharing new commits, branches, or tags with collaborators, and deploying code. <b>git push</b> is essential for collaborative workflows, allowing team members to synchronize their work and maintain a shared version of the project's history.


title: CAVEATS
content:
Using <b>--force</b> or <b>-f</b> can overwrite remote history, potentially causing lost work or severe issues for collaborators if they have based their work on the overwritten history. Always prefer <b>--force-with-lease</b> if you must force, as it checks if the remote branch has been updated by others before forcing. Non-fast-forward updates occur when your local history has diverged from the remote; pushing these without force requires a merge or rebase first. Improper use can lead to a messy repository history.


title: PUSH.DEFAULT CONFIGURATION
content:
The <b>push.default</b> configuration variable dictates the default behavior of <b>git push</b> when no refspec is explicitly provided. Common values include:<br><i><b>simple</b></i>: Pushes the current branch to its upstream branch if their names match. This is the recommended default since Git 2.0.<br><i><b>upstream</b></i>: Pushes the current branch to its upstream branch, regardless of name.<br><i><b>current</b></i>: Pushes the current branch to a branch of the same name on the remote.<br><i><b>matching</b></i>: Pushes all local branches that have a matching branch on the remote. This was the default before Git 2.0 and is generally discouraged.<br><i><b>nothing</b></i>: Disables pushing without a refspec.


title: REFSPECS EXPLAINED
content:
A <i>refspec</i> specifies what <b>git push</b> should push from your local repository to the remote. It typically follows the format <b>[+]&lt;src&gt;[:&lt;dst&gt;]</b>.<br><i><b>src</b></i>: The source reference in your local repository (e.g., a branch name like <i>main</i> or <i>HEAD</i>, or <i>refs/heads/feature</i>).<br><i><b>dst</b></i>: The destination reference on the remote repository (e.g., a branch name like <i>main</i>, or <i>refs/heads/feature</i>). If <i>dst</i> is omitted, it defaults to the same name as <i>src</i>.<br>The <b>+</b> prefix allows a non-fast-forward update for that specific refspec, similar to <b>--force</b> but more granular. Examples:<br><i><b>main</b></i>: Pushes local <i>main</i> to remote <i>main</i>.<br><i><b>feature:new-feature</b></i>: Pushes local <i>feature</i> to remote <i>new-feature</i>.<br><i><b>:feature</b></i>: Deletes the remote <i>feature</i> branch.


title: HISTORY
content:
The <b>git push</b> command has been a core component of Git since its inception in 2005. Its functionality for updating remote repositories is fundamental to collaborative Git workflows. A significant evolution in its usage involved the introduction and changes to the <b>push.default</b> configuration option. Initially, the default behavior might have varied or been less explicit. Over time, defaults like <i>matching</i> (pushing all matching branches) evolved to safer and more explicit defaults like <i>simple</i> (pushing the current branch only if its upstream branch matches and exists on the remote), to prevent accidental pushes of multiple branches. This reflects a maturation towards more explicit and controlled remote interactions.


title: SYNOPSIS
content:
<b>git quiltimport</b> [--dry-run] [--author=&lt;author&gt;] [--mbox] [--patches=&lt;dir&gt;] [--series=&lt;file&gt;] [--keep-tree] [--prefix=&lt;patch-prefix&gt;] [--suffix=&lt;patch-suffix&gt;]


title: PARAMETERS
content:
<b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not actually apply any patches; just show what would be done.<br><br><b><b>--author=&lt;author&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the author for all imported commits. If omitted, the author is extracted from the patch header's 'From:' line.<br><br><b><b>--mbox</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat patches as mbox format. By default, patches are expected to be plain diffs.<br><br><b><b>--patches=&lt;dir&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Look for patches and the 'series' file in the specified directory <i>&lt;dir&gt;</i> instead of the default "patches" directory.<br><br><b><b>--series=&lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>&lt;file&gt;</i> as the series file instead of "series" within the patch directory.<br><br><b><b>--keep-tree</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;After importing, keep the Git working tree clean. This means the import happens in a temporary index and then committed.<br><br><b><b>--prefix=&lt;patch-prefix&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>&lt;patch-prefix&gt;</i> to the name of each patch when looking it up in the patches directory, useful for filename mismatches.<br><br><b><b>--suffix=&lt;patch-suffix&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>&lt;patch-suffix&gt;</i> to the name of each patch when looking it up in the patches directory, similar to <b>--prefix</b>.<br><br>


title: DESCRIPTION
content:
<i>git-quiltimport</i> imports a quilt patchset from a specified directory (defaulting to "patches") and applies each patch as a new Git commit. It constructs the commit message for each commit from the patch's header comments (e.g., 'Subject:', 'From:', 'Date:') followed by the patch's body.<br><br>The command requires a "series" file within the patch directory, which dictates the order of patches. This utility bridges Git and Quilt workflows, enabling users to efficiently migrate Quilt-managed patches into Git's commit history, or to integrate patches initially managed by Quilt directly into a Git repository. It is particularly useful for projects transitioning from Quilt-based patch management to Git, ensuring that the historical record of individual patch applications is accurately preserved.


title: CAVEATS
content:
The command strictly expects a quilt-like directory structure, including a 'series' file listing patches. Patches are primarily expected to be plain diffs unless the <b>--mbox</b> option is used. The successful extraction of commit metadata relies heavily on well-formed patch headers.


title: PATCH FORMAT INTERPRETATION
content:
By default, <i>git-quiltimport</i> expects patches to be standard diffs. The <b>--mbox</b> option alters this behavior, enabling the command to parse patches as individual emails, extracting sender, date, and subject from email headers.


title: COMMIT MESSAGE SOURCE
content:
The commit message for each imported commit is automatically generated from the patch's header comments (lines like 'Subject:', 'From:', 'Date:', etc.) followed by the main body of the patch (content after the '---' separator).


title: HISTORY
content:
<i>git-quiltimport</i> serves as a critical bridge for interoperability between Git and older patch management tools like Quilt. Its development likely arose from the practical need for projects to smoothly transition from Quilt-based workflows to Git while preserving their extensive patch history, or for developers accustomed to Quilt to seamlessly integrate their changes into a Git repository. It reflects Git's broader design philosophy of being highly adaptable and accommodating diverse development practices.


title: SYNOPSIS
content:
<b>git read-tree</b> [<options>] <tree-ish> [<tree-ish>...]<br><b>git read-tree</b> --empty<br><b>git read-tree</b> --reset [<tree-ish>]<br><b>git read-tree</b> --merge [-u | -m] [<common-tree-ish>] <tree-ish-1> <tree-ish-2>


title: PARAMETERS
content:
<b>--empty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Empty the index. This option clears all current index contents.<br><br><b>--reset [<tree-ish>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reset mode. Reads the tree into the index, replacing its current contents. If <tree-ish> is omitted, it defaults to the HEAD tree.<br><br><b>-m, --merge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Merge mode. Requires two or three <tree-ish> arguments (common, ours, theirs). It attempts to merge the trees into the index. Conflicts will result in the index being left in a conflicted state.<br><br><b>-u, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the files in the working tree with the content of the index. This option is implied by --merge when the index is not already populated.<br><br><b>-i, --index-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the index info. Useful when merging multiple trees that might have different file modes or names.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be verbose. Show progress information.<br><br><b>-n, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dry run. Do not actually read the tree into the index or update the working tree. Only show what would be done.<br><br><b>--prefix=<path>/</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prepend <path>/ to the paths in the tree object. This is useful for placing a tree's contents into a subdirectory.<br><br><b>--aggressive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Deprecated for --merge mode, internal use only) Attempts an aggressive merge.<br><br><b>--no-sparse-checkout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not enable sparse checkout even if the index format version is V4.<br><br><b>--recurse-submodules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When reading a tree that contains submodules, recursively populate the contents of the submodule directory.<br><br><b>--no-recurse-submodules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not recursively populate submodules. This is the default.<br><br><b>--trivial-merge-mode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a trivial merge strategy (internal).<br><br><b>--no-trivial-merge-mode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use a trivial merge strategy (internal).<br><br><b><tree-ish></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An object name (e.g., commit, tree, tag) that refers to a tree object. One or more can be specified depending on the mode.<br><br>


title: DESCRIPTION
content:
<i>git-read-tree</i> is a low-level <b>plumbing</b> command in Git used to read tree objects into the index. It directly manipulates the Git index, which is the staging area for the next commit. Unlike porcelain commands like <i>git add</i> or <i>git commit</i>, <i>git-read-tree</i> operates at a fundamental level, allowing advanced users or scripts to construct complex index states.<br><br>It can read one or more trees, merging them into the current index content based on specified options. This command is crucial for operations like <i>git checkout</i>, <i>git merge</i>, and <i>git reset</i> under the hood, as these commands often need to reconstruct the index from specific tree states. Its primary use is for building an index from a specific tree or trees, often to prepare for a commit or to set up a working directory.


title: CAVEATS
content:
<i>git-read-tree</i> is a <b>plumbing</b> command, meaning it's a low-level operation primarily for scripting or internal Git use. Direct manual use requires a deep understanding of Git's internal object model and index structure.<br><br>Incorrect use can lead to a corrupted index or unexpected working tree state, potentially requiring a <i>git reset --hard</i> to recover.<br><br>When used without <i>-u</i> or <i>--merge -u</i>, it only updates the index, not the working directory. Changes in the index will not be visible in your files until explicitly updated.


title: MODES OF OPERATION
content:
<i>git-read-tree</i> can operate in several distinct modes:<br><b>Simple Mode (<i>git read-tree &lt;tree-ish&gt;</i>):</b> Reads the contents of a single tree into the index, overwriting its current contents. This is useful for completely replacing the index with a specific commit's tree state.<br><br><b>Merge Mode (<i>git read-tree -m [&lt;common-tree-ish&gt;] &lt;tree-ish-1&gt; &lt;tree-ish-2&gt;</i>):</b> Attempts to merge two (or three, if a common base is provided) trees into the index. It performs a three-way merge if three tree-ishes are given, or a two-way merge otherwise. This is the underlying mechanism for <i>git merge</i>.<br><br><b>Reset Mode (<i>git read-tree --reset [&lt;tree-ish&gt;]</i>):</b> Similar to simple mode, but explicitly states the intent to replace the index. If no <i>&lt;tree-ish&gt;</i> is given, it defaults to the tree from <i>HEAD</i>.<br><br><b>Empty Mode (<i>git read-tree --empty</i>):</b> Clears the entire index, making it completely empty.


title: HISTORY
content:
<i>git-read-tree</i> is one of the foundational <b>plumbing</b> commands in Git, present since its early development by Linus Torvalds. It's fundamental to how Git manages its staging area (the index) and performs operations like merging and checking out. Its core functionality has remained consistent, although options have been added over time to support new features like sparse checkout or submodule handling. It embodies Git's content-addressable filesystem nature, allowing direct manipulation of tree objects.


title: SEE ALSO
content:
git-write-tree(1), git-commit-tree(1), git-update-index(1), git-ls-files(1), git-checkout-index(1), git-merge(1), git-reset(1)


title: SYNOPSIS
content:
<b>git-reauthor</b> [<i>options</i>] [<i>&lt;commit-range&gt;</i>]<br><br><i>Note: This synopsis represents a common implementation pattern for a 'git-reauthor' script, not a universally defined built-in Git command. Specific scripts may vary in their arguments and functionality.</i>


title: PARAMETERS
content:
<b><b>--map</b> <i>&lt;map_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file containing rules for mapping old author/committer identities to new ones. Each line typically defines an '<i>&lt;old_email&gt; &lt;new_name&gt; &lt;new_email&gt;</i>' pattern or similar structured mapping.<br><br><b><b>--old-email</b> <i>&lt;email&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The old author or committer email address to match for replacement.<br><br><b><b>--new-email</b> <i>&lt;email&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The new email address to assign to matched commits.<br><br><b><b>--new-name</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The new name to assign to matched commits.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the reauthoring process to all commits in the repository's entire history.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a simulation of the reauthoring process, showing potential changes without actually modifying the repository history.<br><br><b><i>&lt;commit-range&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional Git commit range (e.g., <i>HEAD~5..HEAD</i>, <i>&lt;commit-hash&gt;</i>) to limit the reauthoring to a specific set of commits. If omitted, the script's behavior depends on its implementation, often implying <b>--all</b> or <i>HEAD</i>.<br><br>


title: DESCRIPTION
content:
The term "<b>git-reauthor</b>" refers to a common utility script, rather than a built-in Git command, designed to modify the author and committer information of commits within a Git repository's history.<br><br>Its primary function is to correct or unify commit identities, addressing issues like misspelled names, incorrect email addresses, or different identities used for the same person. These scripts typically leverage powerful Git history rewriting tools such as <b>git filter-branch --env-filter</b> or the more modern and faster <b>git filter-repo</b>.<br><br>When executed, a <b>git-reauthor</b> script iterates through a specified set of commits, transforms environment variables like <i>GIT_AUTHOR_NAME</i>, <i>GIT_AUTHOR_EMAIL</i>, <i>GIT_COMMITTER_NAME</i>, and <i>GIT_COMMITTER_EMAIL</i>, and then recreates the commits with the new information. This process fundamentally rewrites history, resulting in new commit SHAs for affected commits and all their descendants. Consequently, pushing these changes to a shared remote repository requires a force-push (e.g., <b>git push --force-with-lease</b>). It is a powerful but potentially destructive operation, best performed on a fresh clone of the repository and with a backup.


title: CAVEATS
content:
<b>Not a Built-in Command:</b> <b>git-reauthor</b> is not part of the standard Git distribution but is a common name for user-created or community-maintained scripts.<br><b>History Rewriting:</b> It fundamentally rewrites Git history, changing commit SHAs. This makes all affected commits (and their descendants) entirely new objects.<br><b>Force Pushing Required:</b> After rewriting history, pushing to a shared remote repository necessitates a force-push (e.g., <b>git push --force-with-lease</b>), which can be disruptive for collaborators.<br><b>Data Loss Risk:</b> Always perform this operation on a fresh clone of the repository and ensure you have a backup of the original repository to prevent irreversible data loss.<br><b>Performance Considerations:</b> For very large repositories, scripts relying on <b>git filter-branch</b> can be slow. Modern implementations often use <b>git filter-repo</b> for significantly better performance.<br><b>GPG Signatures:</b> Rewriting commits invalidates any existing GPG signatures on those commits.


title: TYPICAL USAGE SCENARIO
content:
A common use case for a <b>git-reauthor</b> script is when a developer accidentally commits with a personal email address to a professional repository, or vice-versa. The script provides a streamlined way to correct the author/committer details across multiple commits consistently.


title: BEST PRACTICES FOR SHARED REPOSITORIES
content:
Before force-pushing rewritten history to a shared repository, it is crucial to communicate with all collaborators. They must be informed to fetch the new history and rebase or reset their local branches accordingly to avoid creating divergent histories and potential merge conflicts.


title: HISTORY
content:
The necessity to modify commit authorship in Git history has existed since the early days of Git. Initially, users would construct complex <b>git filter-branch --env-filter</b> commands manually. Over time, various scripts emerged to automate this tedious process, with '<b>git-reauthor</b>' becoming a widely recognized and descriptive name for such a utility. These scripts encapsulate the filtering logic, simplifying the management of author and committer mappings. The evolution of more efficient tools like <b>git-filter-repo</b> has led many newer <b>git-reauthor</b> implementations to switch from <b>filter-branch</b> for improved performance. The widespread use of these scripts highlights a common Git maintenance task rather than the development of a single, official command.


title: SYNOPSIS
content:
<br><b><I>git rebase</I></b> [<I>options</I>] [<I>upstream</I>] [<I>branch</I>]<br><b><I>git rebase</I></b> [<I>options</I>] <B>--onto</B> <I>newbase</I> [<I>upstream</I>] [<I>branch</I>]<br><b><I>git rebase</I></b> [<I>options</I>] (<B>--continue</B> | <B>--abort</B> | <B>--quit</B> | <B>--skip</B> | <B>--edit-todo</B>)


title: PARAMETERS
content:
<b><b>-i</b> or <b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Engage interactive rebase, allowing modification of individual commits (e.g., pick, reword, edit, squash, fixup, drop, exec).<br><br><b><b>--onto</b> <I>newbase</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reapply commits from the current branch, which are not in <I>upstream</I>, onto a new base commit specified by <I>newbase</I>.<br><br><b><b>--continue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resume the rebase operation after resolving conflicts or performing an edit action.<br><br><b><b>--abort</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Terminate the rebase process and reset the branch to its state before the rebase began.<br><br><b><b>--quit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop the rebase process, but keep the current state of the working directory and index as they are. Does not revert changes.<br><br><b><b>--skip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip the current commit that caused a conflict and proceed to the next commit in the rebase sequence.<br><br><b><b>--autosquash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically mark commits for 'squash' or 'fixup' if their message starts with 'squash! <subject>' or 'fixup! <subject>' during interactive rebase.<br><br><b><b>--rebase-merges</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to re-create merge commits during the rebase, preserving their structure. This is an advanced option for complex histories.<br><br><b><b>--root</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebase all commits reachable from the specified branch, up to the initial commit of the repository, rather than just up to an <I>upstream</I>.<br><br><b><b>--exec</b> <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute an arbitrary shell <I>command</I> after each commit during an interactive rebase. Useful for running tests or checks.<br><br>


title: DESCRIPTION
content:
<br>The <I>git-rebase</I> command is a powerful tool for rewriting commit history. It allows you to move, combine, or edit a sequence of commits, making your project's history cleaner and more linear. Unlike <I>git merge</I>, which integrates changes by creating a new merge commit, <I>git rebase</I> reapplies commits from one branch onto another, effectively changing their base. This results in a linear history, which can be easier to read and understand, especially in a collaborative environment.<br><br>Common uses include:<br><b>• Cleaning up local commits:</b> Before pushing to a shared remote, you can use interactive rebase to squash small, incremental commits into logical units, reword commit messages, or drop unnecessary commits.<br><b>• Integrating upstream changes:</b> Instead of merging upstream changes into your feature branch, you can rebase your feature branch onto the latest upstream branch. This makes it look like you started your feature branch from the very latest code, avoiding unnecessary merge commits.<br><b>• Moving commits:</b> Rebase can move a series of commits from one base to another, effectively detaching them from their original history and reattaching them elsewhere.<br><br>While highly beneficial for maintaining a clean project history, <I>git-rebase</I> rewrites commit SHAs. This makes it a potentially dangerous operation on branches that have already been pushed to a shared remote, as it can cause divergence for other collaborators. Therefore, the general rule of thumb is: "Do not rebase published history."


title: CAVEATS
content:
<br><b>1. Rewrites History:</b> <I>git rebase</I> fundamentally changes the SHA-1 hashes of rewritten commits. This is the primary reason why it's generally advised <b>not</b> to rebase branches that have already been pushed to a shared remote repository. Doing so can cause significant history divergence for other collaborators, requiring complex resolution (e.g., force pushing and then other users having to re-clone or reset).<br><b>2. Force Pushing:</b> If you rebase a branch that was previously pushed, you will need to use <I>git push --force</I> or, preferably, <I>git push --force-with-lease</I> to update the remote. <I>--force-with-lease</I> is safer as it prevents overwriting remote work if someone else has pushed to the same branch since your last pull.<br><b>3. Conflict Resolution:</b> Rebasing can lead to conflicts if the changes being rebased conflict with the target branch. Resolving these conflicts can be repetitive and challenging, especially across many commits.<br><b>4. Complexity:</b> While powerful, interactive rebase can be complex. Missteps can lead to lost commits or a convoluted history if not handled carefully. Always ensure you have a backup or know how to use <I>git reflog</I> to recover.


title: CONFLICT RESOLUTION DURING REBASE
content:
<br>When <I>git rebase</I> encounters conflicts, it pauses and allows you to resolve them. The process is similar to resolving merge conflicts:<br><b>1. Identify conflicts:</b> Git will tell you which files have conflicts. Use <I>git status</I> to see them.<br><b>2. Edit files:</b> Open the conflicted files and manually resolve the differences. Remove Git's conflict markers (<<<<<<<, =======, >>>>>>>).<br><b>3. Stage changes:</b> After resolving, use <I>git add &lt;file&gt;</I> for each modified file.<br><b>4. Continue rebase:</b> Run <I>git rebase --continue</I>. Git will then apply the next commit or finish the rebase.<br><br>If you wish to skip a problematic commit, use <I>git rebase --skip</I>. To abandon the entire rebase operation, use <I>git rebase --abort</I>.


title: INTERACTIVE REBASE COMMANDS
content:
<br>When using <I>git rebase -i</I>, Git opens an editor with a list of commits and instructions. Each line represents a commit, prefixed by a command. You can modify these commands to alter the history:<br><b>• pick</b> <I>(p)</I>: Use the commit as is.<br><b>• reword</b> <I>(r)</I>: Use the commit, but edit the commit message.<br><b>• edit</b> <I>(e)</I>: Use the commit, but pause for amending the commit (e.g., fix a bug, split into multiple commits).<br><b>• squash</b> <I>(s)</I>: Use the commit, but merge it into the previous commit. A new commit message will be created combining both.<br><b>• fixup</b> <I>(f)</I>: Like <I>squash</I>, but discards this commit's log message.<br><b>• drop</b> <I>(d)</I>: Remove the commit.<br><b>• exec</b> <I>(x)</I>: Run a shell command on the commit.<br><b>• break</b> <I>(b)</I>: Pause the rebase at the current point, allowing manual intervention before continuing.


title: HISTORY
content:
<br><I>git-rebase</I> has been a fundamental command in Git since its early days, reflecting Linus Torvalds' preference for a linear, clean project history. It was designed to provide an alternative to merge commits, allowing developers to integrate upstream changes by re-applying their local work on top of the latest upstream commits. The core functionality of reapplying commits was present from very early Git versions.<br><br>The addition of the <B>--interactive</B> (<B>-i</B>) option significantly enhanced <I>git-rebase</I>'s power and flexibility. This feature, which enables users to reorder, squash, edit, or drop individual commits, transformed rebase from a simple re-application tool into a comprehensive history rewriting utility. It became crucial for preparing clean, logical commit sets before sharing them.<br><br>More recent developments include options like <B>--rebase-merges</B>, which attempts to preserve merge commits during a rebase, addressing a long-standing limitation where rebase would flatten all history. This makes rebase viable for repositories with complex merge-based workflows. The command continues to evolve with improvements aimed at making it safer and more robust, especially concerning conflict resolution and integration with different workflows.


title: SEE ALSO
content:
<br><b><I>git-merge(1)</I></b>: Integrates changes from one branch into another by creating a new merge commit., <br><b><I>git-cherry-pick(1)</I></b>: Applies a single commit from one branch onto another. Rebase can be seen as automated cherry-picking of a series of commits., <br><b><I>git-reflog(1)</I></b>: Records updates to the tip of branches and other references. Essential for recovering from mistakes during rebase., <br><b><I>git-reset(1)</I></b>: Resets the current HEAD to a specified state, often used to undo local commits or resolve rebase issues.


title: SYNOPSIS
content:
<code>git-rebase-patch &lt;patch-file&gt;</code><br>(<b>Note:</b> This command is an internal helper and is not meant for direct user invocation.)


title: PARAMETERS
content:
<b><code>&lt;patch-file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the patch file (e.g., a diff or mbox format) to be applied. This is typically an internally generated patch representing a commit being rebased.<br><br>


title: DESCRIPTION
content:
<code>git-rebase-patch</code> is an <I>internal helper script</I> used by the <code>git rebase</code> command. It is not intended for direct invocation by end-users. Its primary purpose is to apply individual patches generated during a rebase session, particularly when <code>git rebase</code> is configured to use the <code>am</code> (apply-mbox) backend for patch application or during interactive rebase operations involving <code>am</code> or <code>apply</code> actions.<br>It ensures that patches are applied consistently, handling details like whitespace, sign-off lines, and merge conflicts in a manner suitable for rebase's incremental application of commits. This script forms a crucial part of how <code>git rebase</code> reconstructs commit history by replaying changes.


title: CAVEATS
content:
This command is an <I>internal helper script</I> for <code>git rebase</code> and is not designed for direct user interaction. Its interface and behavior can change without notice between Git versions. Direct invocation by users is strongly discouraged, as it may lead to an inconsistent repository state or unexpected behavior outside the controlled environment of <code>git rebase</code>. Users experiencing issues with patch application during rebase should consult <code>git rebase</code> documentation and troubleshoot through its mechanisms, rather than attempting to debug <code>git-rebase-patch</code> directly.


title: INTERNAL USAGE CONTEXT
content:
<code>git-rebase-patch</code> is typically invoked by <code>git rebase</code> when it needs to apply a single commit from the original series onto the new base. Depending on the rebase mode (e.g., interactive rebase with <code>am</code> action, or standard rebase that internally uses <code>am</code> machinery), <code>git rebase</code> extracts a commit as a patch and passes it to <code>git-rebase-patch</code> for application.


title: ERROR HANDLING
content:
When <code>git-rebase-patch</code> encounters conflicts or other issues during patch application, it typically signals this back to the <code>git rebase</code> process, which then pauses the rebase, allowing the user to resolve the conflict (e.g., via <code>git status</code>, <code>git diff</code>, <code>git add</code>, <code>git rebase --continue</code>).


title: HISTORY
content:
The <code>git-rebase-patch</code> script emerged as part of the internal implementation details of the <code>git rebase</code> command. Its existence is tied to the mechanism by which <code>git rebase</code> 'replays' commits by generating and applying patches. While a specific version number for its introduction is not easily pinpointed without deep Git source archaeology, its function has been integral to <code>git rebase</code>'s patch application process for a long time, evolving alongside the <code>rebase</code> command itself.


title: SYNOPSIS
content:
git-receive-pack [--quiet] [--stateless-rpc] [--exec-cmd=<I>cmd</I>] [--exec-path=<I>path</I>] [--not-from-email] <I>directory</I>


title: PARAMETERS
content:
<b><I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the Git repository where changes will be received.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output from <b>git-receive-pack</b>.<br><br><b>--stateless-rpc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable stateless RPC mode, typically used with the smart HTTP protocol to handle requests that do not maintain state across multiple connections.<br><br><b>--exec-cmd=<I>cmd</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For internal use. Specifies the command to execute, overriding the default Git command logic.<br><br><b>--exec-path=<I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For internal use. Specifies the path to search for Git programs when executing internal commands.<br><br><b>--not-from-email</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For internal use. Indicates that the operation is not originating from an email-based push (e.g., <b>git-am</b>).<br><br>


