# CommandSection

title: PARAMETERS
content:
<b>&lt;commit-range&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The range of commits whose author should be changed. This could be a single commit hash, a range like <i>HEAD~3..HEAD</i>, or <i>ALL</i> for the entire history.<br><br><b>&lt;new-author-name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the individual to whom blame should be reassigned.<br><br><b>&lt;new-author-email&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The email address associated with the new author.<br><br>


title: DESCRIPTION
content:
The <i>git-blame-someone-else</i> command is <b>not a standard, built-in Git command</b>. It's a popular conceptual joke or a custom alias/script found in developer communities, often implemented to humorously or demonstrably alter Git commit history.<br><br>Its primary purpose is to illustrate how one <i>could</i> hypothetically modify past commits to attribute changes to a different author. This typically involves powerful Git history-rewriting tools like <i>git filter-branch</i>, <i>git rebase --exec</i>, or simply <i>git commit --amend</i> for the most recent commit. While conceptually amusing, performing such operations on shared repositories is highly discouraged as it rewrites immutable history, causing inconsistencies for collaborators and requiring a force push. It serves more as a cautionary tale or a demonstration of Git's flexibility rather than a recommended practice for legitimate version control.


title: CAVEATS
content:
<b><I>git-blame-someone-else</I> is NOT a standard Git command.</b> It represents a dangerous practice of rewriting history.<br><br><b>History Rewriting:</b> Modifying past commits fundamentally changes the repository's history, requiring a <i>git push --force</i> to update remote repositories.<br><br><b>Breaks Collaboration:</b> Force-pushing rewritten history on shared branches can cause significant issues for collaborators, leading to lost work or complex recovery scenarios.<br><br><b>Ethical Concerns:</b> Intentionally misattributing authorship is unethical and counterproductive in professional environments.<br><br><b>Mainly for Humor/Learning:</b> Its common usage is as a joke or a demonstration of Git's advanced, powerful, and potentially destructive capabilities.


title: IMPLEMENTATION DETAILS
content:
A conceptual <i>git-blame-someone-else</i> script would typically leverage Git commands like <i>git filter-branch --env-filter</i> to modify author and committer information, or <i>git rebase -i --exec</i> to apply similar changes across a series of commits. For a single recent commit, <i>git commit --amend --author="New Author &lt;email&gt;"</i> is used.


title: ETHICAL IMPLICATIONS
content:
While humorous, actually using a tool to falsely attribute code can have serious consequences. It undermines trust, distorts project history, and can lead to misunderstandings or misjudgment of team members' contributions.


title: HISTORY
content:
The concept of 'blaming someone else' in Git emerged from developer humor and the common scenario of wanting to avoid responsibility for problematic code. It's not a command with a formal development history but rather a meme or a practical joke that demonstrates Git's powerful (and sometimes feared) history-rewriting features. It highlights a recurring theme in software development: the search for culprits when bugs appear.


title: SYNOPSIS
content:
git branch [<options>]<br>git branch [<options>] <branchname> [<start-point>]<br>git branch [<options>] (--delete | -d | -D) <branchname>...<br>git branch [<options>] (--move | -m | -M) [<oldbranch>] <newbranch><br>git branch [<options>] (--copy | -c | -C) [<oldbranch>] <newbranch><br>git branch [<options>] (--list | -r | -a)


title: PARAMETERS
content:
<b><b>-d</b>, <b>--delete</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete the branch. Fails if the branch has unmerged changes.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force delete the branch, even if it has unmerged changes.<br><br><b><b>-m</b>, <b>--move</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rename a branch. Fails if the new branch name already exists.<br><br><b><b>-M</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force rename a branch, overwriting existing branches with the new name.<br><br><b><b>-c</b>, <b>--copy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy a branch. Fails if the new branch name already exists.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force copy a branch, overwriting existing branches with the new name.<br><br><b><b>-r</b>, <b>--remotes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List or delete remote-tracking branches.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List both local and remote-tracking branches.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show SHA-1 and commit subject for each branch.<br><br><b><b>-vv</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show SHA-1, commit subject, and tracking information.<br><br><b><b>--track</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When creating a new branch, set up tracking information.<br><br><b><b>--no-track</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When creating a new branch, do not set up tracking information.<br><br><b><b>--set-upstream-to=&lt;upstream&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set/reset the upstream branch for the current branch.<br><br><b><b>--unset-upstream</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove the upstream information for the current branch.<br><br><b><b>--show-current</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the name of the current branch.<br><br><b><b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List branches (default behavior when no arguments).<br><br><b><b>&lt;branchname&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the branch to create, delete, or rename.<br><br><b><b>&lt;start-point&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The commit from which the new branch will start. Defaults to HEAD.<br><br>


title: DESCRIPTION
content:
The <b>git branch</b> command is a fundamental tool for managing your project's development lines. It allows you to <b>list</b> existing branches, <b>create</b> new ones, <b>delete</b> obsolete ones, and <b>rename</b> branches. When invoked without arguments, it lists all local branches, highlighting the current branch with an asterisk. Branches in Git are lightweight pointers to commits, enabling parallel development streams without significant overhead. This command is crucial for organizing your work, experimenting with new features, and collaborating effectively within a Git repository. While <b>git branch</b> manages the pointers, switching between branches is handled by <i>git checkout</i> or <i>git switch</i>. It also provides options to view remote-tracking branches and set up upstream relationships for easier pushing and pulling.


title: CAVEATS
content:
<b>git branch</b> itself does <i>not</i> switch your working directory or HEAD. To switch to a different branch, use <i>git checkout</i> or <i>git switch</i>. <br>Deleting a branch with <b>-d</b> will fail if it contains unmerged changes; use <b>-D</b> to force deletion, but be cautious as this can lead to lost work. Renaming a local branch that is tracked by a remote branch often requires manual intervention to update the remote reference and avoid confusion.


title: UPSTREAM TRACKING
content:
When a local branch tracks a remote-tracking branch, Git knows which remote branch it corresponds to. This enables simpler <i>git pull</i> and <i>git push</i> operations without specifying the remote or branch name. <b>git branch --set-upstream-to</b> allows you to configure this for existing branches, while <b>git branch &lt;new-branch&gt; --track</b> sets it up on creation.


title: BRANCH NAMING CONVENTIONS
content:
While Git imposes few restrictions, common practice suggests using descriptive, lowercase, hyphen-separated names (e.g., <i>feature/new-login</i>, <i>bugfix/fix-auth</i>). Avoid spaces or special characters. Keeping names concise and clear improves repository readability and collaboration.


title: DETACHED HEAD STATE
content:
Creating a new branch from a specific commit SHA (e.g., <b>git branch my-experiment &lt;sha1&gt;</b>) without immediately checking it out can leave you in a 'detached HEAD' state if you then check out that SHA. <b>git branch</b> itself doesn't cause this, but understanding the relationship between branches, commits, and HEAD is crucial for navigating it.


title: HISTORY
content:
The concept of cheap, flexible branching was a core design principle of Git from its inception, contrasting sharply with earlier VCS systems. The <b>git branch</b> command, being fundamental to this concept, has been part of Git since its earliest versions. While its core functionality remains consistent, various options have been added over time to enhance usability, such as <b>--track</b> for easier upstream setup and <b>-D</b> for forceful deletion. The introduction of <i>git switch</i> in Git 2.23 provided a dedicated command for switching branches, separating it from <i>git checkout</i>'s overloaded functionality, but <b>git branch</b> remains the primary tool for managing branch existence.


title: PARAMETERS
content:
<b>[<I>ref</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a Git reference (e.g., a branch name like <I>main</I>, a tag, or a commit hash like <I>HEAD~1</I>). If omitted, the command typically opens the current branch's page or the repository's root page on the remote host.<br><br><b>[<I>file</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file path relative to the repository root. If provided, the command attempts to open that specific file's view on the remote host. This can be combined with a <I>ref</I> to browse a file at a particular commit or branch (e.g., <I>git browse main README.md</I>).<br><br><b>-r, --remote <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a different remote name (e.g., <I>upstream</I>) to use instead of the default <B>origin</B> when inferring the base URL for the repository.<br><br><b>-u, --url</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of launching a web browser, print the constructed URL to standard output. This is useful for scripting or for users who prefer to open the URL manually.<br><br><b>-i, --issues</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the issues page of the repository on the remote hosting service.<br><br><b>-p, --pulls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the pull requests (or merge requests) page of the repository on the remote hosting service.<br><br><b>-c, --commit <I>hash</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the specific page for a given commit hash. This option is often provided for clarity, even if similar functionality can be achieved by passing a commit hash as a <I>ref</I> argument.<br><br><b>-b, --blame</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When browsing a specific file, open its 'blame' view on the remote host, which shows the last commit that modified each line (if supported by the hosting service).<br><br>


title: DESCRIPTION
content:
The command <i>git-browse</i> is not a standard Git command bundled with the official Git distribution. Instead, it is a widely adopted convenience alias or external script used to quickly open the current Git repository, a specific file, or a commit in the default web browser on its remote hosting service (e.g., GitHub, GitLab, Bitbucket). It typically infers the remote URL from the configured Git remotes (most commonly <B>origin</B>) and constructs the appropriate web URL based on the current branch, commit, or file path within the repository. This functionality saves users from manually copying remote URLs and navigating to them, making it particularly useful for quickly accessing project dashboards, browsing source code online, reviewing pull requests, or checking issue trackers directly from the command line interface.


title: CAVEATS
content:
This command is <B>not part of the official Git distribution</B> and is not universally available by default. Its presence and exact behavior depend on whether it's provided by a third-party tool (such as <I>hub</I> or the <I>gh</I> CLI for GitHub), a custom shell alias, or a user-defined script. Therefore, its functionality, supported options, and how it handles different remote hosting services (GitHub, GitLab, Bitbucket, etc.) can vary significantly between different implementations. Users should consult the documentation for their specific <I>git-browse</I> installation.


title: CONFIGURATION AND HOSTING SERVICES
content:
A robust <I>git-browse</I> implementation typically relies on Git's remote configuration to determine the type of hosting service (e.g., GitHub, GitLab) and then constructs the URL accordingly. Some versions may require additional configuration within the <I>.git/config</I> file or global Git configuration to correctly resolve URLs for less common hosting providers or private Git instances.


title: EXTERNAL DEPENDENCIES
content:
The command usually depends on external tools for launching the web browser. Common dependencies include <I>xdg-open</I> on Linux, <I>open</I> on macOS, and <I>start</I> on Windows. Without these operating system-specific utilities, the command might fail to open the browser, although it could still print the URL if the <I>--url</I> option is used.


title: HISTORY
content:
The concept behind <I>git-browse</I> arose from developers' frequent need to transition from the command line to a repository's web interface. Before its widespread adoption as a convenience alias or script, users would manually copy remote URLs and paste them into their browsers. This repetitive task spurred the creation of various user-contributed scripts and aliases to automate the process. Its utility was eventually recognized by command-line tools designed to extend Git's functionality, such as <I>hub</I> (GitHub's official command-line extension for Git) and <I>gh</I> (the GitHub CLI), which integrated similar browser-opening capabilities, often aliased or named <I>git browse</I>. This effectively 'standardized' the utility in developer workflows, even though it remains an external, rather than built-in, Git subcommand.


title: SYNOPSIS
content:
<b>git browse-ci</b> [<I>options</I>]<br><b>git browse-ci</b> [<I>-p|--print</I>] [<I>-b|--branch &lt;branch&gt;</I>]


title: PARAMETERS
content:
<b>-p, --print</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the generated CI URL to standard output instead of opening it in a web browser.<br><br><b>-b &lt;branch&gt;, --branch &lt;branch&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a branch for which to open the CI page. If not specified, it defaults to the current branch.<br><br>


title: DESCRIPTION
content:
The <i>git browse-ci</i> command opens the Continuous Integration (CI) page associated with the current Git repository in your default web browser.<br>It intelligently detects the CI provider (e.g., GitHub Actions, GitLab CI, Travis CI, Circle CI) by examining the repository's configuration and files. Once detected, it constructs the correct URL for the CI dashboard or pipeline history for the current or specified branch.<br>This command streamlines access to your CI/CD pipelines, allowing quick monitoring of build statuses and test results without manually navigating to the CI platform's website. It's particularly useful for projects integrated with various CI services.


title: CAVEATS
content:
The command relies on heuristics to detect the CI provider. In some complex setups or non-standard configurations, it might not correctly identify the provider or construct the URL.<br>It requires a web browser to be configured and available on the system.<br>For private repositories or CI services requiring authentication, you will still need to be logged into the respective CI platform in your browser.


title: CI PROVIDER DETECTION
content:
<i>git browse-ci</i> attempts to auto-detect the CI provider by looking for specific files (e.g., <i>.gitlab-ci.yml</i>, <i>.github/workflows</i>) or Git configuration (<i>.git/config</i>) entries.<br>Supported providers include GitLab, GitHub Actions, Travis CI, Circle CI, Jenkins, Azure DevOps, Bitbucket Pipelines, and more.


title: ENVIRONMENT VARIABLES
content:
The behavior of <i>git browse-ci</i> can be influenced by environment variables:<br><ul><li><I>GIT_BROWSE_CI_PROVIDER</I>: Force a specific CI provider, overriding auto-detection.<br><li><I>BROWSER</I>: Specify the web browser command to use, e.g., <i>BROWSER=firefox git browse-ci</i>. If not set, it uses system defaults like <i>xdg-open</i> or <i>open</i>.</ul>


title: HISTORY
content:
The <i>git browse-ci</i> command is a component of the popular <i>git-extras</i> project, a collection of useful Git commands that extend Git's core functionality.<br>It was developed to simplify the often tedious process of navigating to various CI/CD platforms for different projects, providing a unified command-line interface for accessing CI build statuses.<br>Its development reflects the increasing adoption of continuous integration practices in modern software development workflows.


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show both local and remote-tracking branches. By default, only local branches are shown.<br><br><b>-r, --remotes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only remote-tracking branches.<br><br><b>--column[=<options>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display output in columns. Options can control layout (e.g., 'always', 'never', 'plain', 'dense').<br><br><b>--sort=<key></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by a specified key, such as 'committerdate' or 'refname'.<br><br><b>&lt;pattern&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter branches by a given shell-style pattern. Only branches matching the pattern will be displayed.<br><br>


title: DESCRIPTION
content:
<b>git-brv</b> is a common alias or custom command in Git environments, typically designed to provide a verbose listing of Git branches. While not a built-in Git command, it usually wraps or is aliased to `git branch -vv` (or `git branch --all -vv`). This command is highly useful for developers to quickly assess the state of their local branches, including their associated upstream tracking branches, and the status relative to their upstream (e.g., "ahead", "behind", "gone").<br><br>The output generally includes the branch name, the SHA-1 hash of its latest commit, the subject line of that commit, and critically, the configured upstream branch with an indicator of how far the local branch is ahead or behind its upstream counterpart. This aggregated view helps in managing branches, especially in collaborative projects, by providing immediate insights into synchronization status.


title: CAVEATS
content:
The exact behavior of <b>git-brv</b> is highly dependent on how it's configured in a user's Git environment. It is most commonly an alias (e.g., `git config --global alias.brv 'branch -vv'`). As such, its available options and specific output format might vary from one system to another. Users should check their Git configuration to confirm its definition if discrepancies are observed.


title: TYPICAL OUTPUT FORMAT
content:
A typical output of <b>git-brv</b> (when aliased to `git branch -vv`) might look like this:<br><br>  `* master  a1b2c3d <I>[origin/master]</I> Commit message here<br>    feature-X 4d5e6f7 <I>[origin/feature-X: ahead 2]</I> Another commit message<br>    develop   8g9h0i1 <I>[origin/develop: behind 5]</I> Yet another commit<br><br>This format indicates the current branch (`*`), the branch name, its commit SHA-1, the upstream tracking branch in italics (if any), and its sync status (e.g., 'ahead 2', 'behind 5').


title: SETTING UP AS AN ALIAS
content:
To set up <b>git-brv</b> as a global alias, you can use the command:<br><br>  `git config --global alias.brv 'branch -vv'`<br><br>For including all branches (local and remote):<br><br>  `git config --global alias.brv 'branch -a -vv'`<br><br>These commands add the alias definition to your `~/.gitconfig` file.


title: HISTORY
content:
The command <b>git-brv</b> does not have a formal historical development as a standalone Git command. Instead, its origin lies in the Git community's need for a quick and convenient way to view verbose branch information. Developers frequently create custom aliases like `git brv` (short for 'branch verbose') to streamline their workflow, combining `git branch` with common options like `-vv` (very verbose) or `-a` (all branches). This practice became widespread due to Git's powerful aliasing capabilities, allowing users to tailor commands to their specific needs and preferences.


title: PARAMETERS
content:
<b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available bugs.<br><br><b>show <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed information for a specific bug by ID.<br><br><b>add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively create a new bug.<br><br><b>edit <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modify the properties of an existing bug.<br><br><b>comment <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a new comment to a specified bug.<br><br><b>close <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Change the status of a bug to closed.<br><br><b>reopen <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reopen a previously closed bug.<br><br><b>labels <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add, remove, or list labels associated with a bug.<br><br><b>web</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start a local web interface for browsing and managing bugs.<br><br><b>fetch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieve bug data from a remote Git repository.<br><br><b>push</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Publish local bug data to a remote Git repository.<br><br>


title: DESCRIPTION
content:
<i>git-bug</i> is a distributed bug tracking system that stores its data directly within a Git repository. Unlike traditional centralized bug trackers (like Jira or Bugzilla), <i>git-bug</i> embraces Git's decentralized nature, allowing developers to track, create, edit, and comment on bugs offline.<br><br>Bug data, including descriptions, comments, and attachments, are stored as Git objects, enabling full version control, history, and synchronization through standard Git operations (push/pull). This architecture provides resilience against single points of failure and allows for a more fluid, branch-based workflow for managing issues, integrating seamlessly with existing Git repositories and workflows. It aims to make bug tracking as decentralized and version-controlled as source code itself.


title: CAVEATS
content:
<ul><li><b>Decentralized Model:</b> While powerful, the distributed nature can introduce complexity in conflict resolution for bug data, similar to code merges.</li><li><b>Learning Curve:</b> Requires familiarity with Git concepts beyond basic usage to fully leverage its distributed features.</li><li><b>Data Storage:</b> All bug data is stored in the Git repository, which can increase repository size, especially with many attachments.</li><li><b>Ecosystem Maturity:</b> As a relatively niche tool, its ecosystem (integrations, tooling) is not as mature as centralized solutions.</li></ul>


title: MERGE CONFLICTS
content:
<i>git-bug</i> stores bug data as Git objects. When multiple users edit the same bug concurrently, merge conflicts can arise, requiring manual resolution similar to code conflicts.


title: WEB INTERFACE
content:
Provides an optional, lightweight web interface for browsing and managing bugs, accessible via the <i><b>git bug web</b></i> command. This offers a more user-friendly view without external dependencies.


title: HISTORY
content:
<i>git-bug</i> was initially created by Michael Brouwer (MichaelMure) to address the desire for a decentralized bug tracking system that seamlessly integrates with existing Git workflows. Development began around 2017-2018, aiming to overcome the limitations of centralized trackers by leveraging Git's core strengths: distribution, version control, and offline capabilities. Its design focuses on treating bugs as first-class Git objects, allowing them to be branched, merged, and pushed like code, thereby enabling a robust, collaborative, and resilient bug management process.


title: SYNOPSIS
content:
git bugreport [--format=<I>format</I>] [--output-directory=<I>path</I>] [--compress=<I>format</I>] [--include-description] [--diagnose-script=<I>script</I>] [--version] [--no-diagnose-script]


title: PARAMETERS
content:
<b><I>--format=<format></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for the bug report. Accepted values are <B>tarball</B> (default) or <B>directory</B>.<br><br><b><I>--output-directory=<path></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the destination directory where the bug report will be created. By default, a temporary directory is used.<br><br><b><I>--compress=<format></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the compression format when the output <I>--format</I> is <B>tarball</B>. Supported formats are <B>gz</B> (default), <B>bz2</B>, or <B>xz</B>.<br><br><b><I>--include-description</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts the user to enter a textual description of the bug, which is then included in the generated report.<br><br><b><I>--diagnose-script=<script></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs an additional, user-provided diagnostic script and includes its output in the report. The script should be executable.<br><br><b><I>--no-diagnose-script</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the execution of the default diagnostic scripts that <b>git-bugreport</b> normally runs to gather system and Git environment information.<br><br><b><I>--version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the <b>git-bugreport</b> command and exits.<br><br><b><I>-h</I>, <I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the command's usage information and exits.<br><br>


title: DESCRIPTION
content:
<b>git-bugreport</b> is a command-line utility designed to assist users in generating comprehensive bug reports for Git. When encountering an issue, providing sufficient diagnostic information is crucial for developers to understand and fix the problem. This command automates the collection of relevant data, ensuring that all necessary details are included without requiring manual compilation.<br><br>It gathers a wide array of information, including the Git version, operating system details, Git configuration settings (both global and repository-specific), and a snapshot of the current repository state (e.g., reflog, <b>git status</b> output, relevant parts of the commit history). Optionally, users can provide a textual description of the bug.<br><br>The collected data is typically packaged into a single tarball or a directory, which can then be easily shared with Git maintainers or developers. By streamlining the report generation process, <b>git-bugreport</b> significantly simplifies the task of reporting issues, helping to expedite troubleshooting and resolution.


title: CAVEATS
content:
When sharing the generated bug report, users should be aware that it may contain potentially sensitive information such as Git configuration, reflog entries, and parts of the repository history. Review the contents before sharing. Additionally, using the <I>--diagnose-script</I> option allows arbitrary code execution, so ensure that any provided script is trusted.


title: INFORMATION GATHERED
content:
The <b>git-bugreport</b> command collects a wide array of diagnostic information to help debug Git issues. This typically includes:<br><br><I>Git Version and Build Information</I>: Details about the Git executable itself.<br><I>Operating System Information</I>: Basic OS details (e.g., kernel version, distribution).<br><I>Environment Variables</I>: Relevant environment variables like <B>GIT_TRACE</B> or <B>PATH</B>.<br><I>Git Configuration</I>: System, global, and repository-specific Git configuration settings.<br><I>Repository Status</I>: Output of <B>git status</B>, <B>git branch -vv</B>, and <B>git remote -v</B>.<br><I>Reflog</I>: The complete reflog for the current repository.<br><I>Active Processes</I>: A list of currently running Git processes.<br><I>Custom Script Output</I>: Output from any script specified with <I>--diagnose-script</I>.<br><I>Bug Description</I>: If <I>--include-description</I> is used, the user's description.<br><br>The collected data aims to provide a comprehensive snapshot of the user's environment and the repository's state at the time of the bug, crucial for replication and diagnosis.


title: HISTORY
content:
<b>git-bugreport</b> was introduced in Git version 2.29.0, released in October 2020. Its primary purpose was to standardize and simplify the process of gathering comprehensive diagnostic data for Git bugs, addressing the common challenge of inadequate information in user-submitted bug reports. It evolved as a specialized tool to capture the necessary context (system, Git environment, and repository state) required by developers for effective troubleshooting.


title: SYNOPSIS
content:
<b>git-bulk</b> [<I>options</I>] <I>command</I>...<br><b>git-bulk</b> [<I>options</I>] <b>-p</b><br><b>git-bulk</b> [<I>options</I>] <b>--help</b>


title: PARAMETERS
content:
<b><b>-d</b> &lt;directory&gt;, <b>--directory</b> &lt;directory&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the root directory to search for Git repositories. Defaults to the current working directory if not provided.<br><br><b><b>-r</b> &lt;pattern&gt;, <b>--repos</b> &lt;pattern&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A regular expression pattern to match repository names (directory names) to include in the operation. Only repositories whose names match this pattern will be processed.<br><br><b><b>-x</b> &lt;pattern&gt;, <b>--exclude</b> &lt;pattern&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A regular expression pattern to match repository names (directory names) to exclude from the operation. Repositories matching this pattern will be skipped.<br><br><b><b>-j</b> &lt;jobs&gt;, <b>--jobs</b> &lt;jobs&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of parallel jobs to run commands across repositories. A value of <b>0</b> (zero) will attempt to use all available CPU cores, providing maximum parallelism.<br><br><b><b>-s</b>, <b>--no-status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the initial <b>git status</b> check that <i>git-bulk</i> performs on each repository before executing the specified command. This can speed up operations on very large numbers of repositories.<br><br><b><b>-i</b>, <b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables interactive mode. For each found repository, the user will be prompted to confirm whether the command should be run, allowing granular control over execution.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, providing more detailed information about the scanning process, command execution, and results for each repository.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output, showing only errors or critical information. This is useful for scripting where minimal output is desired.<br><br><b><b>-p</b>, <b>--path-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only prints the absolute paths of the Git repositories found, without executing any command. This mode is useful for generating lists of repositories that can be piped to other commands.<br><br><b><b>--no-colors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colored output in the terminal, which can be useful in environments that do not support ANSI escape codes or for logging purposes.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message, including usage instructions and a list of all available options, and then exits.<br><br><b><I>command</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Git command (e.g., <b>pull</b>, <b>status</b>) or any arbitrary shell command and its arguments that will be executed for each found Git repository. <i>git-bulk</i> changes directory into each repository before running this command.<br><br>


title: DESCRIPTION
content:
<i>git-bulk</i> is a command-line utility designed to streamline operations across a collection of Git repositories. Instead of manually navigating into each repository and executing a Git command, <i>git-bulk</i> automates this process. It scans a specified root directory for Git repositories and allows users to run any arbitrary Git command, or even a shell command, against each found repository. This tool is particularly useful for managing monorepos or projects with numerous loosely coupled repositories, facilitating tasks like pulling updates, checking statuses, or pushing changes in bulk. Its options allow for parallel execution, filtering repositories by name, and controlling output verbosity.


title: CAVEATS
content:
<i>git-bulk</i> is not a native Git command but a standalone utility that requires separate installation. Its functionality relies on discovering Git repositories based on the presence of a <b>.git</b> sub-directory; non-standard repository structures might not be detected. Running arbitrary shell commands carries security considerations, especially with untrusted inputs. Users should carefully review output as error handling for individual repository commands can vary. Performance scales with the number of repositories, command complexity, and parallelism settings.


title: INSTALLATION
content:
<i>git-bulk</i> is typically installed as a standalone script. One common method involves downloading it directly (e.g., using <b>curl</b>) or via package managers (if available for your system). It is crucial to ensure the script is executable and placed in a directory listed in your system's <b>PATH</b> environment variable for direct command-line access.


title: REPOSITORY DISCOVERY
content:
<i>git-bulk</i> identifies Git repositories by searching for directories that contain a <b>.git</b> sub-directory. This standard detection method ensures compatibility with most common repository setups. It efficiently traverses the directory tree from the specified root (using the <b>-d</b> option) to locate all eligible repositories before executing commands.


title: HISTORY
content:
While the general concept of bulk Git operations existed in various custom scripts, the <i>johnste/git-bulk</i> implementation emerged as a popular, user-friendly, and well-maintained tool. It gained traction by simplifying common multi-repository workflows, offering features like parallel execution and flexible repository filtering, addressing a need not natively covered by Git itself.


title: SYNOPSIS
content:
<b>git bundle create</b> <i>&lt;file&gt;</i> [<i>&lt;git-bundle-option&gt;</i>...] [<i>&lt;git-rev-list-option&gt;</i>...]<br><b>git bundle verify</b> <i>&lt;file&gt;</i><br><b>git bundle list-heads</b> <i>&lt;file&gt;</i>


title: PARAMETERS
content:
<b><i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the bundle file to be created, verified, or listed.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all heads (branches and tags) in the bundle, except those that would be excluded by specific options.<br><br><b><b>--branches[=<i>&lt;pattern&gt;</i>]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all branches, or only branches matching the optional glob pattern, in the bundle.<br><br><b><b>--tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all tags in the bundle.<br><br><b><b>--mirror</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all refs (including remote-tracking branches, notes, etc.) and their current states, mimicking a mirror clone.<br><br><b><b>--stdin</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads a list of revision arguments from standard input to specify what to bundle.<br><br><b><b>^<i>&lt;commit&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes commits reachable from <i>&lt;commit&gt;</i> from the bundle. Essential for creating incremental bundles.<br><br><b><i>&lt;commit&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes commits reachable from <i>&lt;commit&gt;</i> in the bundle. Can specify multiple commits or ranges.<br><br><b><b>--progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows progress during bundle creation.<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses progress output during bundle creation.<br><br>


title: DESCRIPTION
content:
The <b>git-bundle</b> command creates a single, self-contained file that encapsulates an entire Git repository or a specific subset of its objects and references. This "bundle" file acts as a transportable repository, allowing for Git operations like cloning or fetching without direct network access to the original repository.<br><br>It's primarily used for:<br><i>- Transferring repositories between systems that lack a shared network.</i><br><i>- Creating portable backups of a repository's history.</i><br><i>- Distributing specific versions or branches of a project.</i><br><i>- Creating "incremental" bundles, which only contain new commits that are not present in a receiving repository, optimizing data transfer.</i><br><br>A bundle file can be "cloned" from or "fetched" from using standard Git commands, just like a remote repository. It includes all necessary Git objects (commits, trees, blobs, tags) and references (branches, tags) as specified during its creation. However, it does not include the working tree content or repository configuration, only the <code>.git</code> directory's core data.


title: CAVEATS
content:
A bundle file cannot be directly pushed to; it is read-only for client operations (clone/fetch).<br>Bundles only contain the Git object database and references, not the working tree files.<br>Once created, a bundle is a static snapshot; changes in the original repository are not reflected in existing bundles.


title: INCREMENTAL BUNDLES
content:
One of the most powerful uses of <b>git-bundle</b> is creating incremental bundles. This involves specifying a commit or branch that the recipient already has, ensuring the bundle only contains objects <i>not</i> reachable from that known commit. For example, to create a bundle of new commits on <i>main</i> since a specific commit <i>ABCDEF</i> (known to exist on the receiver), you would use: <br><br><i>git bundle create my-update.bundle main --not ABCDEF</i><br><br>This significantly reduces the bundle size for updates.


title: CONSUMING A BUNDLE
content:
To use a created bundle, you can treat it like a remote repository URL. The most common ways are:<br><br><i>git clone my-repo.bundle my-new-repo</i><br><br>...or if you have an existing repository and want to fetch from the bundle:<br><br><i>git fetch my-repo.bundle master</i><br><br>This allows the receiving repository to pull in the history and objects contained within the bundle file.


title: HISTORY
content:
The <b>git-bundle</b> command was introduced early in Git's development (around Git 1.5.0, circa 2007) to address the need for transferring repositories in disconnected environments. It provided a robust alternative to simpler methods like <code>git-archive</code> for maintaining full repository history and enabling operations like cloning or fetching from a single file. Over time, features like <b>verify</b> and <b>list-heads</b> were added to enhance its utility for managing and inspecting bundle files.


title: SYNOPSIS
content:
<i>git cat-file</i> <i>(-t | -s | -e | -p | <type>)</i> <I>&lt;object&gt;</I><br><i>git cat-file</i> <i>(--batch | --batch-check[=<format>])</i> <i>[--buffer]</i> <i>[--unordered]</i> <i>[--format=<format>]</i><br><i>git cat-file</i> <i>(--filters | --textconv)</i> <I>&lt;object&gt;</I><br><i>git cat-file</i> <i>--path=&lt;path&gt;</i> <I>&lt;tree-ish&gt;</I>


title: PARAMETERS
content:
<b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of the content, show the object’s type (e.g., <b>blob</b>, <b>tree</b>, <b>commit</b>, <b>tag</b>).<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of the content, show the object’s size in bytes.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with a zero status if the object exists and is a valid Git object. Otherwise, exit with non-zero status.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pretty-print the contents of the object. For commits and tags, this includes parsed headers and formatted messages. For trees, it lists contents like <i>git ls-tree</i>. For blobs, it prints the raw content.<br><br><b><type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the expected object type. If the object is not of this type, <i>git cat-file</i> will exit with an error. Valid types are <b>blob</b>, <b>tree</b>, <b>commit</b>, and <b>tag</b>.<br><br><b><object></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the object to show. This can be a SHA-1 hash, a branch name, a tag name, or any other object name understood by Git (e.g., <i>HEAD</i>, <i>HEAD~1</i>).<br><br><b>--path=<path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with a tree-ish object (e.g., a commit or tree hash), it extracts the content of the specified path from that tree. This is useful for retrieving specific file versions without checking out the whole tree.<br><br><b>--batch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable batch mode. Object names are read from standard input, and for each name, the object’s type, size, and content are printed to standard output.<br><br><b>--batch-check[=<format>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <i>--batch</i>, but only the type and size information (and optionally other metadata specified by <i>format</i>) are printed, not the content. This is faster for just checking object metadata.<br><br><b>--buffer</b><br>&nbsp;&nbsp;&nbsp;&nbsp;In batch mode, enable buffering of output for potentially better performance. Only applies to <i>--batch</i> and <i>--batch-check</i>.<br><br><b>--unordered</b><br>&nbsp;&nbsp;&nbsp;&nbsp;In batch mode, allows input object names to be unordered. This can be slower as it requires a separate object lookup for each input line, rather than potentially reading contiguous parts of the packfile.<br><br><b>--format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for <i>--batch-check</i>. Placeholder sequences (e.g., <i>%(objectname)</i>, <i>%(objecttype)</i>, <i>%(objectsize)</i>) can be used to define the output string.<br><br><b>--filters</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with a <b>blob</b> object and a <i>--path</i>, apply all relevant filters (e.g., textconv, smudge, clean filters) before displaying its content.<br><br><b>--textconv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <i>--filters</i>, but specifically applies only the text conversion filter (if configured) before displaying the <b>blob</b>'s content.<br><br><b>--no-textconv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable text conversion for <i>--path</i> or <i>--filters</i>. Useful when raw content is desired even if textconv is configured.<br><br><b>--no-filters</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable all filters for <i>--path</i>. Useful when raw content is desired even if filters are configured.<br><br>


title: DESCRIPTION
content:
<i>git cat-file</i> is a low-level "plumbing" command in Git, designed to provide information about the objects stored in the repository's object database. It allows users and scripts to inspect the type, size, or raw content of various Git objects such as <b>blobs</b> (file contents), <b>trees</b> (directory structures), <b>commits</b> (snapshots of the repository at a specific time), and <b>tags</b> (references to specific commits or other objects).<br><br>This command is crucial for understanding Git's internal mechanics and is frequently used by higher-level "porcelain" commands or custom scripts that need direct access to Git's object model. It can output the object's type, its byte size, or its actual content to standard output. For multiple object lookups, its batch modes offer significant performance advantages.


title: CAVEATS
content:
<i>git cat-file</i> is a low-level "plumbing" command, meaning it's primarily intended for scripting and internal Git operations rather than direct daily use by end-users. <br><br>When retrieving content of <b>blob</b> objects, the output can be binary data, which might not be readable in a standard terminal. <br><br>The <i>--path</i> option retrieves content from a <b>tree</b> object directly without checking out the file, but it doesn't apply any working tree attributes or filters by default unless <i>--filters</i> or <i>--textconv</i> are explicitly used. <br><br>For performance, batch modes (<i>--batch</i>, <i>--batch-check</i>) are highly recommended when looking up multiple objects, as they significantly reduce the overhead compared to invoking <i>git cat-file</i> repeatedly for each object.


title: PLUMBING VS. PORCELAIN
content:
<i>git cat-file</i> exemplifies a 'plumbing' command, which operates at a low level directly on Git's internal data structures (the object database). In contrast, 'porcelain' commands (like <i>git commit</i> or <i>git branch</i>) provide a user-friendly interface for common operations, often utilizing multiple plumbing commands internally.


title: GIT OBJECT MODEL
content:
This command directly interacts with Git's fundamental object types: <b>blobs</b> (raw file data), <b>trees</b> (directory listings that map names to blobs or other trees), <b>commits</b> (snapshots of the repository, including author, committer, message, and parent commits), and <b>tags</b> (references to specific commits or objects, often annotated with messages and signatures).


title: HISTORY
content:
<i>git cat-file</i> has been a core component of Git since its inception, dating back to the very early versions (e.g., 0.99.x released in 2005). Its fundamental purpose of directly inspecting the Git object database has remained unchanged. Over time, features like the <i>--path</i> option for extracting specific file contents from trees, and particularly the efficient <i>--batch</i> and <i>--batch-check</i> modes, were added to enhance its utility for plumbing scripts requiring high-performance access to multiple objects. It continues to be a crucial tool for understanding and building upon Git's internal object model.


title: PARAMETERS
content:
<b><B>--format</B> <I>&lt;fmt&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for the changelog, e.g., <I>markdown</I>, <I>json</I>, <I>html</I>.<br><br><b><B>--output</B> <I>&lt;file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the generated changelog to the specified file instead of standard output.<br><br><b><B>--tag-range</B> <I>&lt;tag1&gt;..<tag2&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates the changelog for commits between two specified Git tags.<br><br><b><B>--since</B> <I>&lt;date&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes commits more recent than the specified date or commit hash.<br><br><b><B>--until</B> <I>&lt;date&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes commits older than the specified date or commit hash.<br><br><b><B>--no-merges</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes merge commits from the generated changelog output.<br><br><b><B>--scope</B> <I>&lt;scope&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters commits by a specific scope, often used with Conventional Commits patterns.<br><br><b><B>--config</B> <I>&lt;file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file for the changelog generation process.<br><br><b><B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the changelog tool and exits.<br><br>


title: DESCRIPTION
content:
The <I>git-changelog</I> command is a powerful utility designed to automate the creation of project changelogs directly from a Git repository's commit history. It parses commit messages, tags, and branches to compile a structured, human-readable log of changes between specified versions or dates.<br><br>Instead of manually compiling release notes, <I>git-changelog</I> tools analyze the commit graph, categorize changes (e.g., features, bug fixes, breaking changes) based on conventional commit messages (like <I>Conventional Commits</I> or <I>Semantic Release</I> conventions), and format them into a consistent output, often Markdown. This automation significantly reduces the effort required for release management, ensures accuracy, and promotes consistent documentation across releases.<br><br>It's particularly useful in Continuous Integration/Continuous Deployment (CI/CD) pipelines, where a changelog can be automatically generated upon new releases or merges to the main branch. The tool can be configured to filter commits by author, date range, or specific tags, and to customize the output format to integrate seamlessly with project documentation.


title: CAVEATS
content:
The effectiveness and accuracy of <I>git-changelog</I> tools are highly dependent on consistent and well-structured Git commit messages. Adherence to conventions like <I>Conventional Commits</I> is crucial for automatic categorization and filtering. <I>git-changelog</I> is not a built-in Git command; it typically refers to third-party tools or scripts that need to be installed separately. Behavior and options can vary significantly between different implementations.


title: COMMIT MESSAGE CONVENTIONS
content:
For optimal results, <I>git-changelog</I> tools highly recommend following a structured commit message convention, such as <I>Conventional Commits</I>. These conventions define a standard format for commit messages (e.g., <I>feat(scope): add new feature</I>, <I>fix(auth): resolve login bug</I>), enabling the changelog generator to automatically categorize changes into sections like 'Features', 'Bug Fixes', 'Breaking Changes', etc. Without consistent conventions, the tool's ability to produce a well-organized and meaningful changelog is significantly limited.


title: INTEGRATION WITH CI/CD
content:
<I>git-changelog</I> commands are frequently integrated into Continuous Integration/Continuous Deployment (CI/CD) pipelines. This allows for automated changelog generation as part of the build or release process. For instance, a new changelog entry can be appended to a <I>CHANGELOG.md</I> file, or a full changelog generated and published, whenever a new version is tagged or a release branch is merged. This automation ensures that documentation is always up-to-date with releases without manual intervention.


title: HISTORY
content:
The concept of automatically generating changelogs from Git history emerged from the need to streamline release processes and improve documentation consistency. Initially, changelogs were often compiled manually, a tedious and error-prone task. As Git became the dominant version control system, developers sought ways to leverage its rich commit history. This led to the development of various independent scripts and tools, often named <I>git-changelog</I>, across different programming languages (e.g., Python, Node.js, Ruby, Go). These tools typically abstract away the complexities of parsing <B>git log</B> output, applying rules for categorization, and formatting into standard documentation formats. Their evolution is closely tied to the rise of conventions like <I>Conventional Commits</I> and the adoption of CI/CD practices, making automated changelog generation an integral part of modern software development workflows.


title: PARAMETERS
content:
<b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not output ignored paths, just exit with a status of 0 if any path is ignored, or 1 otherwise. This is useful for scripting.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show details of the matching pattern, including the ignore file, the line number within that file, and the pattern itself. This is the default output format when pathnames are provided as arguments.<br><br><b>-n, --non-matching</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show non-matching (not-ignored) paths as well. By default, only ignored paths are shown. When combined with <b>--verbose</b>, it will also show patterns that *would* have matched if the path wasn't already tracked (though <i>git-check-ignore</i> doesn't consider tracking status for ignore checks directly).<br><br><b>--stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read pathnames from standard input, one per line. This is useful for processing a large number of paths.<br><br><b>-z, --null</b><br>&nbsp;&nbsp;&nbsp;&nbsp;With <b>--stdin</b>, pathnames are separated by a NUL character instead of a newline. In verbose output, fields are also separated by NUL characters and paths are terminated by NUL characters. This is useful for parsing the output reliably in scripts.<br><br>


title: DESCRIPTION
content:
The <i>git-check-ignore</i> command is a powerful utility designed to help users understand and debug Git's ignore rules. It takes one or more pathnames as arguments and checks whether these paths are ignored by Git, according to the rules defined in <i>.gitignore</i> files, the global excludes file (configured via <i>core.excludesFile</i>), or the <i>.git/info/exclude</i> file.<br><br>Unlike <i>git status</i>, which merely lists ignored files, <i>git-check-ignore</i> provides granular detail about *why* a file is ignored. In its default verbose mode, it outputs the path, the specific ignore file containing the matching pattern, the line number within that file, and the exact pattern that caused the ignore. This makes it invaluable for troubleshooting scenarios where files are unexpectedly ignored or not ignored, or for testing new ignore patterns before committing them.


title: CAVEATS
content:
<i>git-check-ignore</i> specifically checks against Git's ignore rules. It does <b>not</b> consider whether a file is already tracked by Git. If a file is tracked in the repository's history, it will never be ignored by <i>.gitignore</i> rules, regardless of any matching patterns. This command will report such a file as 'not ignored' if no pattern matches, but it won't indicate if it's tracked.<br><br>The order and specificity of ignore rules are crucial. Rules in a <i>.gitignore</i> file in a subdirectory take precedence over rules in a parent directory. Global exclude files and <i>.git/info/exclude</i> also follow specific precedence rules.


title: OUTPUT FORMAT
content:
When using the default verbose output (or <b>-v</b>), <i>git-check-ignore</i> produces output for each path that follows this format:<br><br><i>&lt;source_file&gt;:<I>&lt;line_number&gt;</I>:<I>&lt;pattern&gt;</I>	<I>&lt;pathname&gt;</I></i><br><br>For example: <i>.gitignore:5:*.log	my_app.log</i>. If a path is not ignored (and <b>-n</b> is used), it will typically show a line like <i>::<I>my_file.txt</I></i> (indicating no source file or pattern matched).


title: RULE PRECEDENCE
content:
Git processes ignore rules in a specific order:<br>1. Rules in <i>.gitignore</i> files (from the current directory up to the root, with more specific rules taking precedence).<br>2. Rules in <i>.git/info/exclude</i>.<br>3. Rules in the global exclude file (specified by <i>core.excludesFile</i> in your Git configuration).<br><i>git-check-ignore</i> respects this order when determining which pattern applies to a given path.


title: HISTORY
content:
The <i>git-check-ignore</i> command was introduced in Git version 1.8.2, released in February 2013. Its addition addressed a long-standing need for a direct and explicit way to debug and verify Git's ignore rules, simplifying the often-complex task of managing and understanding <i>.gitignore</i> files.


title: SYNOPSIS
content:
<b>git check-mailmap</b> [--[no-]strict] [--raw] [--] &lt; &lt;in-file&gt;<br><b>git check-mailmap</b> [--[no-]strict] [--raw] [--] &lt;name&gt; &lt;email&gt;


title: PARAMETERS
content:
<b><b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If an entry is not found in the mailmap, the command will exit with an error status (1). Without this option, if an identity is not found, the original identity is outputted as is.<br><br><b><b>--no-strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies the default non-strict behavior: if an entry is not found in the mailmap, the original identity is outputted without error.<br><br><b><b>--raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If an entry is found in the mailmap, the canonicalized identity is outputted. If no entry is found, the original input identity (name and email) is outputted verbatim without any modification.<br><br><b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Separates command-line options from the arguments that follow. Useful when names or emails might otherwise be mistaken for options.<br><br><b><b>&lt;name&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name part of the identity to check, used when providing identity directly as arguments.<br><br><b><b>&lt;email&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The email part of the identity to check, used when providing identity directly as arguments. Can be empty if only a name is provided.<br><br><b><b>&lt; &lt;in-file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads identities from standard input, where each line should contain an identity in the format <I>"Name &lt;email&gt;"</I>.<br><br>


title: DESCRIPTION
content:
The <b>git check-mailmap</b> command is a plumbing command used to canonicalize author and committer identities based on the Git <I>.mailmap</I> mechanism. It reads identity lines (typically <I>"Name &lt;email&gt;"</I>) from standard input or provided as arguments and outputs their canonicalized form to standard output. This is particularly useful when different identities (names and emails) have been used for the same person across a project's history, allowing tools like <I>git shortlog</I> or <I>git log</I> to present a unified view. The command consults <I>.mailmap</I> files located in the current repository's top-level directory, as well as paths specified by the <I>mailmap.file</I> and <I>mailmap.blob</I> configuration variables.


title: CAVEATS
content:
This command relies on the presence and correct configuration of a <I>.mailmap</I> file. If no mailmap is found or configured, it essentially acts as an identity function unless <I>--strict</I> is used. It's primarily a low-level helper for other Git commands, not typically invoked directly by end-users.


title: MAILMAP FILE FORMAT
content:
The <I>.mailmap</I> file contains lines that map old identities to new, canonical ones. Each line can have one of two formats:<br><b><I>Canonical Name &lt;canonical@email&gt; &lt;old@email&gt;</b><br>or<br><b><I>Canonical Name &lt;canonical@email&gt; Old Name &lt;old@email&gt;</b><br>The first format maps an old email to a new name and email. The second format maps an old name and email to a new name and email. Lines starting with <I>#</I> are comments.


title: CONFIGURATION
content:
Git can be configured to look for mailmap files beyond the top-level <I>.mailmap</I> file. The <I>mailmap.file</I> configuration variable can specify a path to an additional mailmap file. The <I>mailmap.blob</I> variable can point to a blob object ID within the repository that contains mailmap entries, allowing for project-wide mailmap definitions to be committed and versioned.


title: HISTORY
content:
The <I>.mailmap</I> feature, which <I>git-check-mailmap</I> supports, has been a part of Git since its early days (around 2007) to address the common issue of multiple identities for the same individual in a project's history. <I>git-check-mailmap</I> itself was introduced as a plumbing command to provide a programmatic interface for this canonicalization, allowing other tools to leverage the mailmap logic without reimplementing it.


title: SYNOPSIS
content:
git check-ref-format [--normalize] [--allow-onelevel] [--strict] [--refspec-gen] [--refspec-parse] <I>refname</I>...


title: PARAMETERS
content:
<b>--normalize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Normalizes the reference name to its canonical form and prints it to standard output. If the name is invalid, an error is printed, and the command exits non-zero.<br><br><b>--allow-onelevel</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permits single-component reference names (e.g., 'foo') which are otherwise considered invalid by default. Without this option, names like 'master' would be rejected as invalid if not prefixed with 'refs/heads/'.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies stricter validation rules, disallowing certain common names (like 'HEAD', 'MERGE_HEAD', etc.) unless they are fully qualified (e.g., 'refs/heads/HEAD'). Also disallows names that resemble SHA-1 object IDs.<br><br><b>--refspec-gen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates and prints a canonical refspec string from the input refname, useful for <I>git fetch</I> or <I>git push</I> commands. For example, 'master' might become 'master:refs/heads/master'.<br><br><b>--refspec-parse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses a refspec string and prints its components: source, destination, force flag, and pattern. This helps in understanding how Git interprets complex refspec strings.<br><br>


title: DESCRIPTION
content:
The <B>git-check-ref-format</B> command is a low-level utility used to determine if a given string conforms to the rules for a valid Git reference name (refname). These rules are crucial for ensuring consistency, preventing ambiguity, and avoiding potential security issues within the Git repository. A refname typically points to a commit, tag, or other object within the Git object database.<br><br>The command exits with 0 if the provided refname is valid and a non-zero status otherwise, making it highly suitable for use in scripts and automated workflows. Beyond simple validation, it can also normalize refnames to their canonical form (e.g., `master` to `refs/heads/master`) or parse/generate <B>refspecs</B> used in <I>fetch</I> and <I>push</I> operations. This functionality aids in the correct construction and interpretation of references, which is essential for tools and scripts interacting deeply with Git's internal object model.


title: CAVEATS
content:
Reference names that start with <B>refs/</B> (e.g., <I>refs/heads/master</I>, <I>refs/tags/v1.0</I>) are generally recommended. They are more portable and help avoid conflicts with special Git names (like <I>HEAD</I>) or ambiguities that can arise from single-level references.


title: <B>REFERENCE NAME RULES</B>
content:
Git reference names must adhere to specific rules to be considered valid. They cannot contain certain characters (e.g., <I>~</I>, <I>^</I>, <I>:</I>, <I>?</I>, <I>*</I>), sequences (e.g., <I>..</I>, <I>//</I>), or start/end with specific patterns (e.g., <I>.lock</I>, <I>/</I>). Additionally, they cannot contain non-printable ASCII characters or the DEL character. These rules prevent ambiguity, ensure filesystem compatibility across different operating systems, and mitigate security risks.


title: <B>REFSPEC USAGE</B>
content:
The <I>--refspec-gen</I> and <I>--refspec-parse</I> options are particularly valuable for developers and scripts that programmatically interact with Git's fetching and pushing mechanisms. Refspecs define how local and remote references are mapped during these operations. These options provide a reliable way to correctly construct and interpret these complex strings, ensuring proper synchronization between repositories.


title: HISTORY
content:
<B>git-check-ref-format</B> is a fundamental 'plumbing' command within Git, playing a crucial role in maintaining the integrity and consistency of the repository's reference system. Its rules have evolved over time to enhance robustness, prevent name collisions, and ensure security against directory traversal or command injection via malformed reference names. It underpins many higher-level Git commands that interact with, create, or modify references.


title: SYNOPSIS
content:
<i>git checkout</i> [<options>] <branch><br><i>git checkout</i> [<options>] <commit><br><i>git checkout</i> [<options>] [--] <pathspec>...<br><i>git checkout</i> [<options>] <tree-ish> [--] <pathspec>...<br><i>git checkout</i> -b|-B <new-branch> [<start-point>]<br><i>git checkout</i> -p [<tree-ish>] [--] [<pathspec>...]


title: PARAMETERS
content:
<b><b>-b</b> <i>&lt;new-branch&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new branch named <i>&lt;new-branch&gt;</i> and switch to it.<br><br><b><b>-B</b> <i>&lt;new-branch&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create or reset a branch named <i>&lt;new-branch&gt;</i> and switch to it. If the branch already exists, it will be reset.<br><br><b><b>--track</b> | <b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When creating a new branch, set it up to track an upstream branch.<br><br><b><b>--force</b> | <b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a checkout, even if the index or working tree has uncommitted changes that would be overwritten. Use with caution.<br><br><b><b>--detach</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checkout a commit or tag, leaving <b>HEAD</b> in a detached state. This means you are not on any branch.<br><br><b><b>-p</b> | <b>--patch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively select hunks from the diff to checkout.<br><br><b><b>--ours</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When restoring files, take the version from 'ours' side of a merge (the current branch).<br><br><b><b>--theirs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When restoring files, take the version from 'theirs' side of a merge (the branch being merged).<br><br><b><b>--orphan</b> <i>&lt;new-branch&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new orphan branch, which starts with no history or files. Useful for initial commits or unrelated projects.<br><br><b><b>--quiet</b> | <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most informational messages from the command.<br><br><b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to separate command options from pathspecs, especially when a pathspec might be mistaken for an option.<br><br>


title: DESCRIPTION
content:
The <i>git checkout</i> command is a versatile Git utility used primarily for navigating between branches, commits, or restoring files in your working directory. When used to switch branches, it updates the working tree to match the selected branch, also updating the Git index and moving the <b>HEAD</b> pointer. This allows you to work on different lines of development. When used with a pathspec, it restores specified files from a given tree-ish (like a branch, commit, or the index) into your working tree, or optionally into the index. It's a powerful tool but its dual functionality has led to the introduction of more specialized commands like <i>git switch</i> and <i>git restore</i> to simplify common operations.


title: CAVEATS
content:
The <i>git checkout</i> command is powerful but can be risky if used carelessly. <br><br><b>1. Overwriting Local Changes:</b> Without the <b>--force</b> option, <i>git checkout</i> will refuse to switch branches or restore files if it would overwrite uncommitted local changes. However, if changes are staged, it might overwrite them without warning if they conflict with the checkout target. <br><b>2. Detached HEAD State:</b> Checking out a commit hash or a tag will put Git into a 'detached HEAD' state. Any new commits made in this state will not belong to any branch, making them prone to being lost unless a new branch is explicitly created from them. <br><b>3. Ambiguous Usage:</b> Due to its dual role (branch switching and file restoration), <i>git checkout</i> can be confusing. Modern Git versions (2.23+) introduce <i>git switch</i> for branch operations and <i>git restore</i> for file operations to provide a clearer, safer, and more intuitive interface. While <i>git checkout</i> still works, it's generally recommended to use the newer commands for their specific purposes.


title: DETACHED HEAD STATE
content:
When you checkout a specific commit hash, a remote-tracking branch, or a tag (e.g., <i>git checkout &lt;commit-hash&gt;</i>), you enter a 'detached HEAD' state. In this state, your <b>HEAD</b> pointer is pointing directly to a commit, not to a branch. This means any new commits you make will not automatically update any branch. To save new commits made in a detached HEAD state, you must create a new branch from your current <b>HEAD</b> (e.g., <i>git branch &lt;new-branch-name&gt;</i>).


title: TRANSITION TO <I>GIT SWITCH</I> AND <I>GIT RESTORE</I>
content:
As of Git 2.23, the functionality of <i>git checkout</i> has been logically split into two more intuitive commands: <i>git switch</i> for changing branches and <i>git restore</i> for restoring files from the index or another tree-ish. While <i>git checkout</i> still works, the new commands offer clearer semantics and are generally recommended for new users and modern workflows. For instance, instead of <i>git checkout &lt;branch&gt;</i>, use <i>git switch &lt;branch&gt;</i>; instead of <i>git checkout -- &lt;file&gt;</i>, use <i>git restore &lt;file&gt;</i>.


title: HISTORY
content:
For a long time, <i>git checkout</i> served as the primary command for both switching branches and restoring files. Its original design was to be a single 'checkout' command that could manipulate both the <b>HEAD</b> and the working tree/index. <br><br>However, this dual functionality often led to confusion, especially for new users, as the same command had different behaviors depending on whether a branch/commit or a path was provided as an argument. <br><br>Recognizing this ambiguity and potential for user error, Git 2.23 (released in August 2019) introduced two new, more focused commands: <i>git switch</i> and <i>git restore</i>. These commands explicitly separate the responsibilities of <i>git checkout</i>. <i>git switch</i> handles branch operations, and <i>git restore</i> handles file restoration. While <i>git checkout</i> remains available for backward compatibility, its use for these specific tasks is largely superseded by the newer, clearer commands.


title: SYNOPSIS
content:
<b>git checkout-index</b> [<I>options</I>] [--] [<I>file</I>...]<br><b>git checkout-index</b> <I>--stdin</I> [<I>options</I>]


title: PARAMETERS
content:
<b>-u, --unmerged</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not abort on unmerged entries. Instead, extract stage #2 (the 'theirs' side) for conflicted paths.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checkout all files in the index. Cannot be used with explicit <I>file</I> paths.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite existing files in the working tree without prompting.<br><br><b>-n, --no-create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not create new files. Only update existing files that match the index content.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress error messages for files that already exist and would be overwritten without <b>--force</b>.<br><br><b>-z, --null</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Input/output paths are NUL-terminated. Useful when combined with commands like <b>git ls-files -z</b>.<br><br><b>--prefix=<path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When checking out, write files to the specified path prefix instead of the current working directory.<br><br><b>--stage=<number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When checking out unmerged entries, select a specific stage number (1, 2, or 3) to extract. Cannot be used with <b>--unmerged</b>. Stage 1 is the base, 2 is 'theirs', and 3 is 'ours'.<br><br><b>--sparse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Respect the sparse-checkout definition when checking out files. Only relevant if sparse-checkout is enabled for the repository.<br><br><b>--index-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read index information from standard input, using the format specified by <b>git update-index --index-info</b>. Primarily for internal or advanced scripting use.<br><br><b>--stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read file paths from standard input, one per line (or NUL-terminated with <b>-z</b>), instead of from command-line arguments.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Separates options from the list of explicit <I>file</I> paths, allowing filenames that start with a hyphen to be specified.<br><br><b><file>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional list of specific files to checkout from the index. If omitted and <b>--stdin</b> is not used, all files are checked out (requires <b>-a</b>).<br><br>


title: DESCRIPTION
content:
<b>git checkout-index</b> is a Git <I>plumbing</I> command used to copy files from the Git <I>index</I> (also known as the staging area) to the <I>working tree</I>. Unlike the higher-level <b>git checkout</b> command, <b>git checkout-index</b> does not update <I>HEAD</I> or switch branches. It's primarily designed for scripting and low-level repository manipulation, allowing precise control over which files are extracted and where they are placed.<br><br>It can be used to restore specific files from the index, inspect the content of the staging area, or prepare files for external tools. It can overwrite existing files if forced, and has options to handle unmerged entries in the index. This command provides a direct interface to the contents of the index, making it powerful for custom Git workflows but less commonly used for routine operations.


title: CAVEATS
content:
<b>git checkout-index</b> is a <I>plumbing</I> command, meaning it's a lower-level building block of Git and is not typically used by end-users directly for day-to-day operations. It does <B>not</B> update your <I>HEAD</I> or move your branch pointer. It can overwrite existing files in your working directory, potentially leading to data loss if not used carefully, especially with the <b>--force</b> option. It also does not manage <I>.git/info/sparse-checkout</I> directly; it respects it if <b>--sparse</b> is used.


title: USE CASES AND LIMITATIONS
content:
While <b>git checkout-index</b> can retrieve files from the index, it's important to understand its limitations. It does not perform merge operations, handle conflicts gracefully (unless specific stages are requested for unmerged paths), or update any Git references. It is best suited for scenarios like:<br><ul><li>Restoring specific files from the staging area that might have been accidentally deleted from the working tree.</li><li>Extracting files from the index into a temporary location for inspection or processing by external tools.</li><li>Building custom Git workflows or scripts that require precise control over the working directory content based on the index.</li></ul><br>For typical <I>checkout</I> operations (e.g., switching branches, restoring files from a commit), the higher-level <b>git checkout</b> or <b>git restore</b> commands are preferred.


title: UNMERGED ENTRIES HANDLING
content:
When the index contains unmerged entries (due to a conflict), <b>git checkout-index</b> normally aborts if it encounters such a path. The <b>--unmerged</b> option forces it to extract stage #2 (the version from 'theirs'). The <b>--stage=&lt;number&gt;</b> option provides more granular control, allowing extraction of stage #1 (base), #2 (theirs), or #3 (ours) for conflicted paths. This is particularly useful in scripting custom merge resolution tools or inspecting conflict states.


title: HISTORY
content:
<b>git-checkout-index</b> has been a core part of Git since its early days, serving as a fundamental tool for manipulating the index and working tree at a low level. It predates many of the user-friendly porcelain commands and remains crucial for Git's internal operations and for advanced scripting scenarios where direct control over the index is required. Its interface has remained relatively stable, reflecting its foundational role in Git's architecture.


title: PARAMETERS
content:
<b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing the full SHA-1 of the commits in addition to the status prefix.<br><br><b><b>&lt;upstream&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The commit (or branch/tag reference) that limits the set of commits considered "applied." Commits in <b>&lt;head&gt;</b> are checked against this range. Defaults to <i>FETCH_HEAD</i> if not specified.<br><br><b><b>&lt;head&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The commit (or branch/tag reference) that defines the set of commits to be checked for application in <b>&lt;upstream&gt;</b>. Defaults to <i>HEAD</i> if not specified.<br><br>


title: DESCRIPTION
content:
The <b>git-cherry</b> command is used to identify commits that exist on one branch but have not yet been applied (either directly or via cherry-pick) to another specified upstream branch. It compares two commit ranges: one representing the "upstream" branch and another representing the "head" branch. Its primary use case is for project maintainers or developers who want to track which patches from a feature branch or fork have been integrated into the main development line.<br><br><b>git-cherry</b> works by computing a "patch ID" for each commit in the <b>&lt;head&gt;</b> range and then checking if a commit with an identical patch ID exists in the <b>&lt;upstream&gt;</b> range. Commits with matching patch IDs are considered "applied," even if their SHA-1 hashes differ due to rebase or cherry-picking. Commits without a match are reported as "missing." It helps determine what work still needs to be pulled upstream or what commits have been successfully integrated.


title: CAVEATS
content:
<b>git-cherry</b> is an approximation and might produce false positives. It explicitly does not take merge commits into account when comparing commit ranges. If a commit from <b>&lt;head&gt;</b> was integrated into <b>&lt;upstream&gt;</b> via a merge commit rather than a cherry-pick or direct application, <b>git-cherry</b> might report it as "missing."<br>The <b>&lt;limit&gt;</b> argument in the synopsis is deprecated and has no effect.


title: <B>OUTPUT</B>
content:
The output of <b>git cherry</b> consists of a list of commits, each prefixed with a status character:<br><b>+</b> (plus sign): Indicates that the commit from the <b>&lt;head&gt;</b> branch appears to be <i>not</i> applied to the <b>&lt;upstream&gt;</b> branch.<br><b>-</b> (minus sign): Indicates that the commit from the <b>&lt;head&gt;</b> branch <i>has</i> been applied to the <b>&lt;upstream&gt;</b> branch.<br>Following the prefix, the commit subject line is displayed. If the <b>-v</b> option is used, the full SHA-1 of the commit is also shown before the subject line.


title: HISTORY
content:
The <b>git-cherry</b> command has been a part of Git since its early days, designed to help developers and maintainers track the integration status of commits. Its purpose aligns with Git's distributed nature, enabling clearer communication and management of patches flowing between different repositories or branches. It specifically leverages the <b>git-patch-id</b> mechanism, which was introduced to provide a stable identifier for a patch's content, regardless of its commit SHA-1, making <b>git-cherry</b> resilient to rebases and cherry-picks.


title: PARAMETERS
content:
<b><b>&lt;commit-ish&gt;...</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more commits to cherry-pick. This can be a commit hash, a branch name, or any Git revision reference.<br><br><b><b>--no-commit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>cherry-pick</i> from automatically committing the changes after applying them. The changes are left in the index and working tree, allowing for further modifications or staging before a manual commit.<br><br><b><b>--edit</b> (or <b>-e</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows editing the commit message before the cherry-pick is committed. A text editor will open with the original commit message, which can be modified.<br><br><b><b>--continue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues the cherry-pick operation after a conflict has been resolved manually. After fixing conflicts and staging the changes (<i>git add</i>), this command completes the operation.<br><br><b><b>--abort</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Aborts the current cherry-pick operation, discarding any changes that have been applied and reverting the working directory and index to the state before the cherry-pick started.<br><br><b><b>--quit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Aborts the current cherry-pick operation but leaves the working directory and index as is (i.e., with conflicts). This is useful if you want to inspect the conflicted state before deciding to fix or fully abort.<br><br><b><b>--strategy=&lt;strategy&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the merge strategy to use during the cherry-pick. Common strategies include 'recursive' (default), 'resolve', 'ours', 'theirs'.<br><br><b><b>-x</b> (or <b>--signoff</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a "Signed-off-by" line by the committer at the end of the commit message.<br><br>


title: DESCRIPTION
content:
The <i>git-cherry-pick</i> command is a powerful Git operation used to apply changes from one or more existing commits to a different branch. Unlike <i>git-merge</i>, which integrates an entire branch's history, <i>cherry-pick</i> allows users to pick specific commits by their SHA-1 hash and reapply their changes. This creates a new commit on the current branch, containing the same changes as the original commit, but with a new commit SHA and often new parentage.<br><br>It's commonly used for "backporting" bug fixes from a development branch to a stable release branch, or for moving a small feature from one branch to another without merging the entire source branch. While convenient for isolated changes, it should be used judiciously, as it can lead to duplicated commits and complex history if not managed carefully.


title: CAVEATS
content:
<ul><li><b>New Commits</b>: <i>git-cherry-pick</i> creates new commits with new SHA-1 hashes. This means the new commit is not the "same" as the original from a Git history perspective, even if the content is identical.</li><li><b>Duplicate History</b>: If a cherry-picked commit is later integrated via a merge, it can lead to duplicate commits in the history, which might complicate future merges or reverts.</li><li><b>Merge Conflicts</b>: Conflicts are common, especially when cherry-picking commits that touch files also modified in the target branch. These require manual resolution.</li><li><b>Parentage</b>: The new commit's parentage will be the tip of the branch it was cherry-picked onto, not the original commit's parent.</li></ul>


title: HANDLING CONFLICTS
content:
When <i>cherry-pick</i> encounters conflicts, it pauses the operation. The user must manually resolve the conflicts in the affected files, stage the changes using <i>git add</i>, and then continue the operation with <b>git cherry-pick --continue</b>. If the resolution is too complex or undesirable, <b>git cherry-pick --abort</b> can be used.


title: BEST PRACTICES
content:
It is generally recommended to use <i>git-cherry-pick</i> for isolated, small changes (e.g., hotfixes, single-line bug fixes) rather than for integrating large features or many commits. For larger integrations, <i>git-merge</i> or <i>git-rebase</i> are often more appropriate to maintain a cleaner and more traceable history.


title: HISTORY
content:
<i>git-cherry-pick</i> has been a fundamental part of Git since its early days, dating back to at least Git version 1.0.0 (released in 2005). It was introduced to address the need for selectively applying individual changes across branches, a common requirement in maintenance branches and bug-fixing workflows. Its utility in backporting specific bug fixes without introducing the overhead of full branch merges quickly solidified its place as a core command, complementing <i>git-merge</i> and <i>git-rebase</i> in managing complex project histories.


title: PARAMETERS
content:
<b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force</i> removal of untracked files and directories. This option is <b>required</b> unless the configuration variable <i>clean.requireForce</i> is set to <i>false</i>.<br><br><b>-n, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show what would be done</i> without actually removing anything. This is highly recommended for safety.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove untracked <i>directories</i> in addition to untracked files.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not consult any ignore files (like <b>.gitignore</b>). Remove <i>all</i> untracked files and directories, including those normally ignored by Git.<br><br><b>-X</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove only files that are <i>ignored</i> by Git. This is useful for cleaning up build artifacts or generated files that are typically listed in <b>.gitignore</b>.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in <i>interactive mode</i>. Git will show what would be done and ask for confirmation before each removal.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress reporting of files removed. Only error messages will be shown.<br><br><b>-e <pattern>, --exclude=<pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a temporary <i>exclude pattern</i>. Files matching this pattern will not be removed or shown in the dry run, similar to an entry in <b>.gitignore</b>.<br><br><b>-- <path>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the cleaning operation to specific <i>paths</i> within the working directory. Untracked files/directories outside these paths will not be affected.<br><br>


title: DESCRIPTION
content:
The <b>git clean</b> command is used to remove untracked files and directories from your working tree. It helps in restoring your working directory to a clean state, similar to a fresh clone, by deleting files that are not part of your Git repository and are not listed in your <b>.gitignore</b>.<br><br>This command is <i>powerful and destructive</i>; once files are removed, they are gone permanently. For safety, it requires the <b>-f</b> (force) option to execute, and it's highly recommended to always perform a <b>--dry-run</b> (<b>-n</b>) first to see what would be removed.


title: CAVEATS
content:
<b>Destructive Nature</b>:<br><i>git clean</i> permanently deletes files and directories from your working tree. There is no undo mechanism within Git for these operations. Always use the <b>-n</b> (dry-run) option first to preview what will be removed.<br><br><b>Force Requirement</b>:<br>The <b>-f</b> or <b>--force</b> option is almost always required to perform any cleaning, serving as a critical safeguard against accidental data loss.<br><br><b>Does Not Affect Tracked Files</b>:<br>This command only operates on untracked files and directories. Files that are tracked by Git (i.e., part of your repository history) are never touched by <i>git clean</i>.<br><br><b>Ignored Files</b>:<br>By default, <i>git clean</i> will not remove files listed in your <b>.gitignore</b>. To remove all untracked files including ignored ones, use <b>-x</b>. To remove <i>only</i> ignored files, use <b>-X</b>.


title: COMMON USAGE PATTERNS
content:
Here are some typical ways to use <i>git clean</i> safely and effectively:<br><br><b>Preview what would be removed (files only)</b>:<br><code>git clean -n</code><br><br><b>Preview what would be removed (files and directories)</b>:<br><code>git clean -fdn</code><br><br><b>Preview what would be removed (all untracked, including ignored)</b>:<br><code>git clean -xfdn</code><br><br><b>Execute removal of untracked files only</b>:<br><code>git clean -f</code><br><br><b>Execute removal of untracked files and directories</b>:<br><code>git clean -fd</code><br><br><b>Execute removal of all untracked files and directories, including ignored ones</b>:<br><code>git clean -xfd</code>


title: HISTORY
content:
The <i>git clean</i> command has been a part of Git since its early days, fulfilling the essential role of helping developers maintain a clean working directory by removing transient or unnecessary files that are not part of the repository's tracked history. Its core functionality has remained consistent, with minor enhancements over time to improve control and safety, such as the addition of interactive mode and more granular ignore options.


title: PARAMETERS
content:
<b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If implemented, typically forces the removal of files without confirmation. Essential for actual deletion when the command is run.<br><br><b>-n, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If implemented, performs a trial run, showing which files and directories would be removed without actually deleting them. Useful for previewing changes.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If implemented, includes files and directories specified by .gitignore in the cleanup process, in addition to untracked files.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If implemented, also removes untracked directories, in addition to untracked files.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A hypothetical option for a more aggressive cleanup, potentially combining actions like <i>git clean</i>, <i>git gc</i>, and even resetting local changes to a pristine state.<br><br><b>--local</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A hypothetical option to specifically target and clear only local, uncommitted changes, potentially by resetting the working directory and index.<br><br><b>-- <paths>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If supported, limits the cleanup operation to specific paths or directories within the repository. Anything outside these paths would be unaffected.<br><br>


title: DESCRIPTION
content:
<i>git-clear</i> is not a standard command distributed with Git. It typically refers to a user-defined alias or a custom script designed to provide a more comprehensive or simplified way to clean up a Git repository's working directory. While the exact behavior depends entirely on its implementation, it commonly aims to remove untracked files, ignored files (if explicitly requested), and potentially prune empty directories or clean up Git's internal garbage. It often serves as a convenience wrapper around standard Git commands like <i>git clean</i>, <i>git reset</i>, or <i>git gc</i>, combining their functionalities for a quicker cleanup workflow. Users often create such scripts to automate repetitive cleanup tasks, such as preparing a repository for a fresh build or ensuring a pristine working state. Due to its custom nature, its functionality can vary widely, from a simple wrapper for <i>git clean -fdx</i> to a more aggressive script that might also prune branches or revert local changes. Always exercise caution when using non-standard cleanup scripts, as they can lead to unintended data loss if not properly understood.


title: CAVEATS
content:
<b>Important:</b> <i>git-clear</i> is not a standard Git command. Its functionality is entirely dependent on how it's implemented (as an alias or a custom script) by an individual user or team. Using it without understanding its source code can lead to irreversible data loss. Always inspect the underlying script or alias definition before execution, especially in production environments or with critical data. Its behavior can differ significantly from similar standard Git commands like <i>git clean</i>.


title: HOW TO IMPLEMENT (HYPOTHETICAL EXAMPLE)
content:
A common way to define a <i>git-clear</i> command is through a Git alias or a shell script. For instance, you could add <code>git config --global alias.clear 'clean -fdx'</code> to make <code>git clear</code> an alias for <code>git clean -fdx</code>. Alternatively, a more complex script might look like:<br><code>#!/bin/bash<br>git clean -fdx<br>git gc --prune=now<br>echo 'Repository cleared!'</code><br>The actual implementation determines its behavior.


title: SAFETY BEST PRACTICES
content:
Before running any custom cleanup script or alias, especially one named <i>git-clear</i>, it is highly recommended to:<br>1. <b>Inspect its source code:</b> Understand exactly what commands it executes.<br>2. <b>Use dry-run first:</b> If supported (e.g., <i>git clean -n</i>), always preview changes.<br>3. <b>Commit or stash important work:</b> Ensure no valuable uncommitted changes are present.<br>4. <b>Back up:</b> For critical repositories, consider a full backup.


title: HISTORY
content:
As <i>git-clear</i> is not a part of the official Git distribution, it does not have a formal development history. Instead, it represents a common pattern among Git users to create custom aliases or scripts to streamline their workflows. Users often develop such commands to bundle frequently used cleanup operations (e.g., combining <i>git clean</i> with <i>git gc</i> or a hard reset) into a single, memorable command. This trend highlights the extensibility of Git and the community's desire for personalized, efficient tooling.


title: SYNOPSIS
content:
<b>git clear-soft</b> [<b>-n</b>|<b>--dry-run</b>] [<b>-i</b>|<b>--interactive</b>] [<b>-d</b> <i>&lt;directory&gt;</i>|<b>--temp-dir</b> <i>&lt;directory&gt;</i>] [<b>--stash</b>] [<b>--ignore</b>] [<b>--reset-local</b>]


title: PARAMETERS
content:
<b><b>-n</b>|<b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run, showing what <b>would</b> be cleared or acted upon without actually performing the action.<br><br><b><b>-i</b>|<b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables interactive mode, prompting the user before each potential action.<br><br><b><b>-d</b> <i>&lt;directory&gt;</i>|<b>--temp-dir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Moves untracked files to the specified <i>directory</i> instead of deleting them.<br><br><b><b>--stash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stashes current uncommitted changes (both staged and unstaged) into the Git stash.<br><br><b><b>--ignore</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds untracked files to the project's <i>.gitignore</i> file, preventing them from being tracked in the future.<br><br><b><b>--reset-local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets unstaged changes in the working directory, similar to <b>git restore --staged</b> or <b>git restore &lt;file&gt;</b>, effectively undoing staging or local modifications without data loss.<br><br>


title: DESCRIPTION
content:
The <b>git-clear-soft</b> command is <i>not</i> a standard Git command. It is a hypothetical or user-defined script/alias intended to provide a 'soft' method for handling untracked files or unstaged changes within a Git repository. Unlike `git clean -f`, which permanently deletes untracked files, <b>git-clear-soft</b> aims to manage these items without destruction. <br><br>Potential 'soft' actions could include: <br><i>- Moving untracked files to a temporary directory.</i><br><i>- Stashing local modifications (both staged and unstaged).</i><br><i>- Adding untracked files to the project's .gitignore file to prevent future tracking.</i><br><i>- Performing a soft reset to unstage changes without losing them.</i><br><br>The exact behavior of <b>git-clear-soft</b> would depend entirely on its implementation, typically as a custom shell script or Git alias defined by a user or project.


title: CAVEATS
content:
The <b>git-clear-soft</b> command is <i>not</i> a built-in or standard Git command. Its existence and behavior are entirely dependent on it being a user-defined alias, a custom shell script, or a third-party utility. Users should verify its implementation if they encounter it in a shared environment, as its functionality can vary greatly. There is no official manual page or universal specification for this command.


title: TYPICAL IMPLEMENTATION
content:
This command would typically be implemented as a shell script placed in the user's PATH (e.g., <i>~/bin/git-clear-soft</i>) or as a Git alias configured in the Git configuration file (e.g., <i>~/.gitconfig</i> or <i>.git/config</i>). An example alias could be: <br><code>git config alias.clear-soft '!f() { git stash --include-untracked && git clean -dn && echo "Untracked files and changes safely handled."; }; f'</code>


title: HISTORY
content:
As <b>git-clear-soft</b> is not a standard command, it has no official development history. Any 'history' would pertain to its individual creation and usage within specific projects or user environments as a custom solution to manage untracked files and local changes non-destructively, often as an alternative to the more aggressive `git clean` command.


title: PARAMETERS
content:
<b>-o, --output <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the generated changelog to <I>FILE</I> instead of standard output.<br><br><b>-c, --config <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom path to the configuration file (default is <CODE>cliff.toml</CODE>).<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite the output file if it already exists without prompting.<br><br><b>-s, --sort <FIELD></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort commits by <I>newest</I> or <I>oldest</I> date within each section.<br><br><b>-t, --tag <TAG></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate the changelog for changes associated with a specific <I>TAG</I>.<br><br><b>-l, --latest</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate the changelog for changes since the latest Git tag.<br><br><b>-u, --unreleased</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate the changelog for all unreleased changes (since the last tag).<br><br><b>-p, --prepend</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prepend the new changelog content to an existing output file.<br><br><b>--init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a boilerplate <CODE>cliff.toml</CODE> configuration file in the current directory.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the command.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for git-cliff.<br><br>


title: DESCRIPTION
content:
git-cliff is a <I>fast</I> and <I>highly customizable</I> changelog generator that reads your Git history and produces a structured changelog. It is designed to work seamlessly with the <I>Conventional Commits specification</I>, extracting information such as commit types (features, fixes, etc.), scopes, and breaking changes to organize your releases effectively. The tool provides extensive templating capabilities, allowing users to define the exact format and content of their changelogs using a <I>TOML configuration file</I> (<CODE>cliff.toml</CODE>). This makes it suitable for various project types and release workflows, ensuring consistency and automation in documentation.


title: CAVEATS
content:
<b>Requires Conventional Commits:</b> While highly configurable, git-cliff's full power and structured output are best realized when your Git commit history adheres to the <I>Conventional Commits specification</I>.<br><b>Configuration Complexity:</b> For highly customized changelog outputs, the <CODE>cliff.toml</CODE> configuration file can become quite complex, requiring familiarity with TOML and templating syntax.


title: CONFIGURATION FILE (<CODE>CLIFF.TOML</CODE>)
content:
git-cliff is highly configurable via a <CODE>cliff.toml</CODE> file. This file allows users to define how commits are parsed, how sections are grouped (e.g., features, bug fixes, breaking changes), customize the output template using <I>Jinja2-like syntax</I>, and filter commits based on types, scopes, or tags. This makes it incredibly flexible for diverse project requirements.


title: CONVENTIONAL COMMITS SUPPORT
content:
The tool is built with a strong emphasis on the <I>Conventional Commits specification</I>. It automatically understands commit types like <CODE>feat</CODE>, <CODE>fix</CODE>, <CODE>chore</CODE>, <CODE>docs</CODE>, <CODE>refactor</CODE>, <CODE>perf</CODE>, <CODE>test</CODE>, and <CODE>build</CODE>, and can extract scopes and breaking changes messages to generate a semantically versioned changelog.


title: HISTORY
content:
git-cliff was initially created by <I>Orhun Parmaksız</I> and first released around <I>late 2021</I> (version 1.0.0 in November 2021). It emerged as a modern, Rust-based alternative to existing changelog generators, focusing on performance, extensibility, and strict adherence to the Conventional Commits specification. Its development has been community-driven, with continuous improvements in templating, filtering, and configuration options, making it a popular choice for automated release workflows.


title: PARAMETERS
content:
<b>&lt;repository&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL or path to the remote repository to clone. This can be a local path, an HTTP(S) URL, an SSH URL, or a Git protocol URL.<br><br><b>[&lt;directory&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The optional name of the directory into which the repository will be cloned. If not provided, Git will create a directory with the same name as the repository (minus the .git suffix).<br><br><b>-b &lt;name&gt;,<br>--branch &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository’s HEAD, point to the branch named &lt;name&gt;. In a non-bare repository, this is also the branch that is checked out.<br><br><b>--bare</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make a bare Git repository. That is, rather than creating &lt;directory&gt; and placing the administrative files in &lt;directory&gt;/.git, make the &lt;directory&gt; itself the .git folder. This implies --no-checkout as no working tree is created.<br><br><b>--mirror</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set up a mirror of the source repository. This implies --bare. When a mirror is fetched, all refs, and thus all branches and tags, are updated on the local side.<br><br><b>--depth &lt;depth&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a shallow clone with a history truncated to the specified number of commits. Useful for large repositories where you only need recent history.<br><br><b>-o &lt;name&gt;,<br>--origin &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of using the remote name 'origin' to keep track of the upstream repository, use &lt;name&gt;.<br><br><b>-q,<br>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate quietly. Progress is not reported to the standard error stream.<br><br><b>-n,<br>--no-checkout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;No checkout of HEAD is performed after the clone is complete. The .git directory is initialized, but the working tree is left empty. Useful for server-side cloning where you don't need a working copy.<br><br><b>--single-branch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clone only the history of a single branch, even if the remote has multiple branches. Implies --no-tags unless --no-tags is specified.<br><br><b>--recurse-submodules[=&lt;pathspec&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;After the clone is created, initialize and clone submodules within it. If optional &lt;pathspec&gt; is given, only submodules whose path matches the pathspec are initialized and cloned.<br><br><b>--jobs &lt;n&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of submodules that should be fetched and checked out simultaneously. Defaults to the submodule.fetchJobs configuration option.<br><br>


title: DESCRIPTION
content:
The <b>git clone</b> command is used to create a local copy of an existing Git repository. When you clone a repository, Git downloads all versions of all files and folders for the entire project history, including all branches and tags. This creates a fully functional local Git repository, which includes a remote connection (usually named <i>origin</i>) pointing back to the original source repository. This local copy is then ready for you to start working on, allowing you to make changes, commit them, and push them back to the remote repository, or pull updates from it. It's the first step to contribute to an existing Git project or to get a local copy of your own remote repository.


title: CAVEATS
content:
Cloning large repositories with deep histories can consume significant disk space and network bandwidth.<br>Be cautious when cloning from untrusted sources, as the repository might contain Git hooks that execute malicious code upon cloning or subsequent operations.<br>Shallow clones (using <i>--depth</i>) can sometimes cause issues if you later need to access older history or push changes that conflict with the truncated history. Converting a shallow clone to a full clone requires fetching missing history.


title: DEFAULT BEHAVIOR
content:
By default, <b>git clone</b> fetches all branches and tags from the remote repository, creates a local <i>master</i> (or <i>main</i>, depending on the remote's default branch name) branch, and sets up a remote tracking branch for it, usually named <i>origin/master</i> or <i>origin/main</i>. It then checks out the content of the default branch into your working directory, making it ready for immediate use.


title: PROTOCOL SUPPORT
content:
<b>git clone</b> supports various protocols, including HTTP/HTTPS, SSH, Git protocol (git://), and local filesystem paths. The choice of protocol often depends on authentication requirements and network configuration.


title: HISTORY
content:
The <b>git clone</b> command is one of the foundational commands of Git, present since its very first public release in 2005. It was designed to be simple and efficient, creating a complete, fully independent local copy of a remote repository. Over time, options like <i>--depth</i> (for shallow clones) and <i>--recurse-submodules</i> were added to address specific use cases like large repositories and projects with nested dependencies, enhancing its utility for a wider range of development workflows.


title: PARAMETERS
content:
<b><I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all configured co-authors with their initials, full names, and email addresses.<br><br><b><I>add</I> <I>&lt;initials&gt;</I> <I>&lt;Name&gt;</I> <I>&lt;Email&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new co-author entry to the configuration file. <I>&lt;initials&gt;</I> is a short identifier (e.g., 'ab'), <I>&lt;Name&gt;</I> is the full name, and <I>&lt;Email&gt;</I> is the email address.<br><br><b><I>remove</I> <I>&lt;initials&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a co-author entry from the configuration file identified by its <I>&lt;initials&gt;</I>.<br><br><b><I>use</I> <I>&lt;initials&gt;...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which co-authors should be added to the next commit. Multiple initials can be provided space-separated. This typically creates or updates a temporary file that a Git <I>prepare-commit-msg</I> hook reads.<br><br><b><I>edit</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the co-author configuration file in your default editor for manual editing.<br><br><b><I>clear</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears the list of co-authors that were set to be used for the next commit.<br><br>


title: DESCRIPTION
content:
The <I>git-coauthor</I> command is a utility designed to streamline the process of adding 'Co-authored-by:' trailers to Git commit messages. This is particularly useful in collaborative development environments such as pair programming or mob programming, where multiple individuals contribute to a single commit. The command typically manages a local configuration file (e.g., <I>~/.git-coauthors</I>) that maps short initials to full names and email addresses.<br><br>When invoked, it appends the relevant 'Co-authored-by:' lines to the commit message, ensuring proper attribution and adherence to Git's commit trailer format. This automation saves time and ensures consistency compared to manually typing co-author lines for each collaborative commit.


title: CAVEATS
content:
The <I>git-coauthor</I> command is not a standard component of Git itself. It is typically a third-party script or a custom utility. As such, its specific implementation, available commands, and configuration file location may vary depending on where you obtained it. It commonly relies on Git hooks (specifically <I>prepare-commit-msg</I>) to inject co-author lines into the commit message before it's saved, meaning it may not work as expected if Git hooks are disabled or overridden.


title: HISTORY
content:
The concept of <I>git-coauthor</I> tools emerged from the growing popularity of highly collaborative Git workflows, such as pair programming and mob programming, where multiple individuals contribute to a single commit. While Git natively supports adding 'Co-authored-by:' trailers, manually appending them can be cumbersome. Scripts like <I>git-coauthor</I> began to appear in the community to automate this process, making it easier to manage and apply co-authorship. Its development is largely community-driven, reflecting a common solution to a shared challenge in modern software development.


title: PARAMETERS
content:
<b><b>--command=&lt;name&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that <i>git-column</i> was invoked by <i>&lt;name&gt;</i> to format its output. This influences how column options are looked up in the Git configuration.<br><br><b><b>--[no-]indent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pads each column with two spaces. The default is <b>--no-indent</b>.<br><br><b><b>--[no-]nl</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures the output ends with a newline character. The default is <b>--nl</b>.<br><br><b><b>--[no-]padding</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pads each column with a single space. The default is <b>--padding</b>.<br><br><b><b>--[no-]row-major</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the filling order of columns. With <b>--row-major</b>, data fills rows before columns. The default is <b>--row-major</b> unless otherwise configured.<br><br><b><b>--[no-]sane</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A convenience option equivalent to specifying <b>--padding --indent --nl --row-major</b>, applying a set of 'sane' default formatting options.<br><br><b><b>--mode=(dense|long|plain)</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines how columns are formatted:<br><b>dense</b>: Similar to <i>ls -C</i>, fills columns before rows (column-major).<br><b>long</b>: Fills rows before columns (row-major).<br><b>plain</b>: Does not use columns, outputs lines as-is.<br><br><b><b>--width=&lt;width&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the output width to a specific <i>&lt;width&gt;</i>. By default, it uses the terminal width.<br><br><b><b>--wrap</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wraps input lines at the terminal width, useful for very long lines.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>git-column</i> version information.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message for the command.<br><br>


title: DESCRIPTION
content:
<i>git-column</i> is an internal helper command within Git, primarily designed to display textual data in a columnar format. While not intended for direct invocation by end-users, it serves as the underlying engine for many Git commands that produce structured, human-readable output, such as <i>git-branch</i>, <i>git-tag</i>, <i>git-stash list</i>, <i>git-log --graph</i>, and <i>git-shortlog</i>.<br><br>The command takes input lines and arranges them into columns based on various formatting modes, including <i>dense</i> (column-major, similar to <i>ls -C</i>), <i>long</i> (row-major), or <i>plain</i> (no columns). It offers options for indentation, padding between columns, and control over whether the output ends with a newline. Users can influence its behavior indirectly through Git's configuration system, specifically via the <i>column.ui</i> and <i>column.&lt;command&gt;.ui</i> settings, which dictate how columnar output should appear for different Git subcommands.<br><br>Although not a primary user command, its flexibility in handling columnar display means advanced users or developers might use it directly for testing or custom scripting that requires consistent Git-style columnar output.


title: CAVEATS
content:
<i>git-column</i> is primarily an internal Git helper command and is <b>not</b> designed for direct end-user interaction. While it can be invoked manually for testing or experimentation, its main purpose is to provide consistent columnar output for other Git subcommands. Its options and behavior are often implicitly controlled by Git's configuration system, rather than direct command-line arguments by the user.


title: CONFIGURATION
content:
The behavior of <i>git-column</i> can be configured through Git's settings, affecting how various Git commands display columnar output:<br><b>column.ui</b>: Defines the default columnar formatting for the user interface. Common values are <i>always</i>, <i>never</i>, or <i>auto</i>, and can also specify modes like <i>dense</i> or <i>long</i>. The default is typically <i>column -x</i> (equivalent to <i>dense</i> mode).<br><b>column.&lt;command&gt;.ui</b>: Allows overriding the <i>column.ui</i> setting for specific Git commands. For example, <i>column.branch.ui</i> can be set to control the display of <i>git branch</i> output, independent of other commands.


title: SYNOPSIS
content:
git commit [-a | --patch] [-m <message> | -F <file>] [--amend] [--no-edit] [-v] [--no-verify] [--dry-run] [-s | --signoff] [-S[<keyid>]] [<pathspec>...]


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically <b>stage all modified and deleted files</b> before committing. New files are not staged unless added explicitly with `git add`.<br><br><b>-m <message>, --message=<message></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the given <b><I>message</I></b> as the commit message. If multiple `-m` options are given, their values are concatenated as separate paragraphs.<br><br><b>-F <file>, --file=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Take the commit message from the given <b><I>file</I></b>. Use `-` to read from standard input.<br><br><b>--amend</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Amend the previous commit. This command is used to <b><I>replace the last commit</I></b> with a new one, combining the changes in the staging area with the changes from the previous commit. It rewrites history.<br><br><b>--no-edit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with `--amend` or `--allow-empty`, this option prevents `git commit` from launching an editor. The commit message is taken from the previous commit or the provided `-m`/`-F` option.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the diff of the changes being committed in the <b><I>commit message editor</I></b>. This can help in crafting a relevant message.<br><br><b>-s, --signoff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a "Signed-off-by: Your Name <your.email@example.com>" line at the end of the commit message, indicating that you agree to the Developer Certificate of Origin (DCO).<br><br><b>-S[<keyid>], --gpg-sign[=<keyid>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;GPG-sign the commit. The `keyid` is optional and defaults to the committer's GPG key.<br><br><b>--no-verify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;This option bypasses the <b><I>pre-commit</I></b> and <b><I>commit-msg</I></b> Git hooks. Useful when you need to commit despite a hook failure.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not create a commit, but show <b><I>what would be committed</I></b> and the proposed commit message. Useful for previewing.<br><br>


title: DESCRIPTION
content:
`git commit` is a fundamental Git command used to <i>permanently record changes</i> from the <i>staging area</i> (also known as the index) into the Git repository. When you make modifications to files in your working directory, these changes are initially untracked or modified. To include them in the next commit, you must first move them to the staging area using `git add`. <br><br>A commit operation creates a new <i>commit object</i>. This object includes a snapshot of your project's files at the time of the commit, metadata such as the author, committer, and timestamp, and a pointer to the parent commit(s). The collection of these commit objects forms the project's history as a <i>Directed Acyclic Graph (DAG)</i>. <br><br>Every commit requires a <i>commit message</i>, which serves as a concise explanation of the changes introduced. A good commit message is crucial for understanding the project's evolution and for collaborative development.


title: CAVEATS
content:
`git commit` only records changes that have been explicitly moved to the <b>staging area</b> (index) using `git add`. A common mistake for new users is to make changes but forget to `git add` them before committing, resulting in an empty commit or missing changes. <br><br>Using `<b>--amend</b>` rewrites the history of your repository. This is generally safe if the commit you are amending has not been pushed to a shared remote repository. If it has, amending and then pushing can cause problems for collaborators who have already pulled that commit, requiring force pushes and potential conflicts. <br><br>An empty commit (a commit with no changes from its parent) is typically not allowed unless you use the `<b>--allow-empty</b>` option.


title: COMMIT MESSAGE BEST PRACTICES
content:
A well-crafted commit message is crucial for project maintainability. Best practices include:<br>1. A <b><I>short, concise subject line</I></b> (50-72 characters) that summarizes the change.<br>2. A <b><I>blank line</I></b> separating the subject from the body.<br>3. A <b><I>detailed body</I></b> (wrapped at 72 characters) explaining <i>what</i> and <i>why</i> the change was made, not just <i>how</i>. Use imperative mood in the subject line (e.g., "Fix bug" instead of "Fixed bug").


title: THE COMMIT OBJECT
content:
In Git, a commit isn't just a record of changes; it's a pointer to a <b><I>complete snapshot</I></b> of your project at a specific point in time. Each commit object contains:<br>1. A pointer to a <b><I>tree object</I></b>, representing the exact state of the working directory at the time of commit.<br>2. Pointers to its <b><I>parent commit(s)</I></b> (one for a regular commit, multiple for a merge commit).<br>3. <b><I>Metadata</I></b>: author, committer, timestamp, and the commit message.


title: HISTORY
content:
The `git-commit` command has been a <b>core and indispensable part</b> of the Git version control system since its initial development by Linus Torvalds in 2005. Its design reflects Git's fundamental philosophy of tracking content snapshots rather than differences, enabling efficient branching and merging. While minor options and behaviors have been refined over the years, the central concept of committing staged changes to build a <b>Directed Acyclic Graph (DAG)</b> of project history has remained consistent and foundational to Git's operation.


title: SYNOPSIS
content:
<b>git commit-graph verify</b> [<I>options</I>]<br><b>git commit-graph write</b> [<I>options</I>] [<I>rev-list options</I>]<br><b>git commit-graph read-config</b>


title: PARAMETERS
content:
<b>--object-dir=<I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Git object directory where graph files are located or should be written.<br><br><b>--split=<I>commit-id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'write', create a new split commit-graph file starting from the specified commit ID.<br><br><b>--split-write-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'write', write information about split commit-graphs to the info file.<br><br><b>--split-merge=<I>commit-id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'write', merge the current split commit-graph with existing graphs, considering commits from the specified ID.<br><br><b>--reachable-from=<I>commit-id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'write', only include commits reachable from the specified commit ID in the graph.<br><br><b>--stdin-commits</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'write', read the list of commits to include in the graph from standard input.<br><br><b>--progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show progress during the commit-graph operation.<br><br><b>--k=<I>number</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'write' with splitting, specifies the number of commits to include in the base graph.<br><br><b>--max-graph-size=<I>number</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'write' with splitting, specifies the maximum size of a split commit-graph.<br><br><b>--changed-paths</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'verify', check for changed paths recorded in the commit-graph.<br><br><b>--shallow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'verify', perform a shallow verification, avoiding full history traversal.<br><br><b>--file=<I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the commit-graph file to operate on for 'verify' or 'read-config'.<br><br><b>--no-lookup-objects</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'verify', skip lookup of objects in the object database for validation, relying only on graph data.<br><br>


title: DESCRIPTION
content:
The <b>git-commit-graph</b> command is a <I>plumbing</I> command used to manage commit-graph files. These files store reachability information for commits in a highly optimized format, significantly speeding up operations like <b>git log</b>, <b>git rev-list</b>, and other commands that traverse the commit history. By pre-calculating and storing parent-child relationships and reachability, Git can avoid recomputing this information on the fly, leading to faster history traversals, especially in large repositories. It can operate on a single commit-graph file or manage a chain of multiple files, which is useful for repositories with frequently changing histories or when incrementally building the graph.


title: CAVEATS
content:
<b>git-commit-graph</b> was introduced in Git 2.19. Older Git versions will not recognize or utilize commit-graph files. While these files significantly speed up read operations, writing them can be resource-intensive, especially for very large repositories without the use of split graphs. They are an optimization and not strictly necessary for basic repository functionality.


title: SPLIT COMMIT-GRAPHS
content:
<I>Split commit-graphs</I> allow a repository to have multiple commit-graph files. This is particularly useful for large, active repositories where rebuilding a single massive graph frequently would be inefficient. A common pattern involves a <I>base graph</I> (containing older, stable history) and a <I>split graph</I> (containing newer, frequently changing history). This enables incremental updates, as only the smaller, more recent split graph needs to be rebuilt or appended, significantly reducing the overhead of keeping the graph optimized. <b>git-commit-graph write</b> with the <I>--split</I> and <I>--split-merge</I> options is used to manage these.


title: HISTORY
content:
<b>git-commit-graph</b> was introduced in <I>Git 2.19</I> (July 2018) as an experimental feature to improve the performance of history traversal. Prior to this, Git would dynamically compute reachability information, which could be slow for very large repositories. The initial implementation focused on basic graph writing and verification. Over subsequent versions, features like split commit-graphs were added (e.g., in <I>Git 2.20</I> and <I>2.21</I>) to allow for more flexible and incremental updates to the graph, making it practical for active repositories with frequent new commits. This has made Git's history commands significantly faster in scenarios where commit-graph files are present and up-to-date.


title: SYNOPSIS
content:
<b>git commit-tree</b> <I>&lt;tree&gt;</I> [<b>-p</b> <I>&lt;parent&gt;</I>...] [<b>-S</b>[<I>&lt;keyid&gt;</I>]] [<b>-m</b> <I>&lt;message&gt;</I>] [<b>-F</b> <I>&lt;file&gt;</I>] [<b>-b</b> <I>&lt;gpgsign_opt&gt;</I>]...


title: PARAMETERS
content:
<b><I>&lt;tree&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The SHA-1 ID of the tree object that this new commit will point to. This tree represents the complete snapshot of the repository's contents at the time of the commit.<br><br><b><b>-p</b> <I>&lt;parent&gt;</I><br><b>--parent=</b><I>&lt;parent&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the SHA-1 ID of a parent commit. This option can be used multiple times to specify multiple parents, which is typical for merge commits. For the initial commit in a repository, no parent should be specified.<br><br><b><b>-m</b> <I>&lt;message&gt;</I><br><b>--message=</b><I>&lt;message&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the commit message directly on the command line. If multiple <b>-m</b> options are given, their values are concatenated into separate paragraphs of the commit message.<br><br><b><b>-F</b> <I>&lt;file&gt;</I><br><b>--file=</b><I>&lt;file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the commit message from the specified <I>&lt;file&gt;</I>. Use <I>-</I> as the <I>&lt;file&gt;</I> to read the message from standard input.<br><br><b><b>-S</b>[<I>&lt;keyid&gt;</I>]<br><b>--gpg-sign</b>[<b>=</b><I>&lt;keyid&gt;</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;GPG-sign the commit. An optional <I>&lt;keyid&gt;</I> can be provided to specify the GPG key to use for signing. If no <I>&lt;keyid&gt;</I> is given, the default signing key will be used.<br><br><b><b>-b</b> <I>&lt;gpgsign_opt&gt;</I><br><b>--gpg-sign-opt=</b><I>&lt;gpgsign_opt&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes additional, specific arguments to the `gpg --sign` command when signing the commit. This option can be specified multiple times.<br><br>


title: DESCRIPTION
content:
The <b>git-commit-tree</b> command is a low-level "plumbing" command in Git, used to create a new commit object directly in the Git object database.<br><br>It takes the SHA-1 ID of a tree object (representing the state of the directory), zero or more parent commit IDs (to define the commit's history), and the commit message. After successfully creating the commit object, it prints its SHA-1 ID to standard output.<br><br>Unlike the higher-level <i>git commit</i> command, <b>git-commit-tree</b> does not automatically stage changes, nor does it interact with the index or worktree. It requires the user to explicitly provide all necessary object IDs, making it suitable for scripting or specialized Git operations rather than routine day-to-day use.


title: CAVEATS
content:
<b>git-commit-tree</b> is a low-level "plumbing" command intended primarily for scripting and advanced Git operations. It does not perform any of the automatic staging, indexing, or worktree interactions that the more common <i>git commit</i> command handles.<br><br>Using this command incorrectly can lead to a corrupted repository history or unreferenced objects. It requires precise knowledge of Git's object model and object IDs.


title: USAGE SCENARIO
content:
A common scenario for using <b>git-commit-tree</b> directly is when programmatically creating commits without a traditional working directory or index, or when building custom Git tools. For example, one might first use <i>git write-tree</i> to create a tree object from a set of files, and then use <b>git-commit-tree</b> to turn that tree into a commit.


title: HISTORY
content:
<b>git-commit-tree</b> is fundamental to Git's design, being one of the core low-level commands that manipulate Git's object database. It has been a part of Git since its early development, reflecting Linus Torvalds' initial approach of building Git from a set of simple, composable tools. Its stable interface allows higher-level commands and external scripts to reliably create commit objects.


title: PARAMETERS
content:
<b><i>&lt;date-string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The required argument specifying the starting date or time for listing commits. Git understands various date formats, including absolute dates (e.g., <i>'2023-01-15'</i>, <i>'2023-01-15T10:30:00'</i>), relative dates (e.g., <i>'yesterday'</i>, <i>'2 weeks ago'</i>, <i>'2 hours and 30 minutes ago'</i>), and specific named dates.<br><br><b><i>&lt;path&gt;...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional paths to limit the commits displayed to those that affected the specified files or directories. This allows focusing on changes within a particular part of the codebase.<br><br><b><b>--author=</b><i>&lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the commits to those whose author matches the specified pattern (a regular expression). Case-insensitive by default.<br><br><b><b>--grep=</b><i>&lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the commits to those whose log message matches the specified pattern (a regular expression). Useful for finding commits related to specific features or bug fixes.<br><br><b><b>--format=</b><i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows customization of the output format for each commit, similar to <code>git log --pretty=format</code>. Common formats include <i>'oneline'</i>, <i>'short'</i>, <i>'medium'</i>, <i>'full'</i>, <i>'fuller'</i>, or custom formats using placeholders.<br><br><b><b>--max-count=</b><i>&lt;num&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the number of commits to output. Displays only the first <i>&lt;num&gt;</i> commits found since the specified date.<br><br><b><b>--oneline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A shorthand for <code>--format=oneline</code>. Each commit is displayed on a single line, showing the commit hash and the first line of the commit message.<br><br><b><b>--no-merges</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes merge commits from the output, showing only 'true' development commits.<br><br><b><b>--stat</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a diffstat (a summary of changes, i.e., files changed, insertions, deletions) for each commit.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Considers all references (e.g., all local branches, remote-tracking branches, and tags) when looking for commits. By default, it operates only on the current branch.<br><br>


title: DESCRIPTION
content:
The <b>git-commits-since</b> command is designed to provide a focused view of a Git repository's history, specifically listing all commits that have occurred <i>after</i> a specified date or time. It acts as a convenient wrapper or specialized script around Git's powerful <code>git log</code> command, simplifying the process of querying recent changes.<br><br>This utility is particularly useful for quickly reviewing daily progress, identifying changes made since a last deployment, or tracking development activity over a specific period. By accepting a wide range of date formats, from absolute timestamps like '2023-10-26' to relative expressions such as '2 weeks ago' or 'yesterday', it offers flexibility in historical navigation.<br><br>While not a standard Git command, <b>git-commits-since</b> addresses a common need for streamlined chronological commit retrieval, often implemented by users or community projects to enhance their Git workflow. It typically provides a clean, chronological list of commit IDs, authors, dates, and commit messages, with options to customize the output or filter results further.


title: CAVEATS
content:
<b>git-commits-since</b> is <i>not</i> a standard command shipped with Git itself. It typically refers to a custom script or an external tool that wraps <code>git log --since</code>. Therefore, its availability, exact behavior, and supported options may vary significantly depending on the system or environment. Users should confirm if such a script exists and its specific implementation before relying on it.<br><br>The accuracy of date parsing can sometimes be affected by locale settings or the specific version of Git/script being used. Performance may be impacted on very large repositories or when specifying a very old date, as Git needs to traverse a potentially extensive history.


title: DATE FORMATS
content:
Git's date parsing is quite flexible. The <i>&lt;date-string&gt;</i> can be:<br><i>&nbsp;&nbsp;&nbsp;</i>An absolute date: <i>'YYYY-MM-DD'</i>, <i>'YYYY-MM-DDTHH:MM:SS'</i>, <i>'MM/DD/YYYY HH:MM:SS'</i>.<br><i>&nbsp;&nbsp;&nbsp;</i>Relative dates: <i>'yesterday'</i>, <i>'last monday'</i>, <i>'2 weeks ago'</i>, <i>'3 days 4 hours ago'</i>, <i>'1.second.ago'</i>.<br><i>&nbsp;&nbsp;&nbsp;</i>Named dates: <i>'now'</i>.<br><i>&nbsp;&nbsp;&nbsp;</i>Epoch timestamps: <i>'@1672531200'</i> (for Jan 1, 2023, 00:00:00 UTC).<br><br>The specific parsing capabilities depend on the underlying Git version and the environment's C library (e.g., <code>strtotime</code>-like functions if used in a script).


title: DEFAULT BEHAVIOR
content:
When <b>git-commits-since</b> is invoked with only a <i>&lt;date-string&gt;</i>, it typically lists commits starting from that date on the <i>current branch</i>. The output format is usually a concise summary (similar to <code>git log</code>'s default or <code>--oneline</code>), showing the commit hash, author, date, and subject line. To see commits across all branches or in a different format, specific options like <code>--all</code> or <code>--format</code> must be used.


title: HISTORY
content:
The concept behind <b>git-commits-since</b> emerged from the frequent need to filter Git history by date, a common use case for developers and project managers. While Git's native <code>git log --since</code> option provides this functionality, users often create custom scripts or aliases to simplify its invocation, add specific default behaviors, or integrate it into larger workflows.<br><br>This command represents a pattern for such a convenience wrapper, making the powerful date-filtering capabilities of <code>git log</code> more accessible and memorable without requiring the full syntax of <code>git log</code> and its date-specific options.


title: SYNOPSIS
content:
<b>git config</b> [<i>--local</i> | <i>--global</i> | <i>--system</i> | <i>--worktree</i> | <i>-f &lt;file&gt;</i> | <i>--blob &lt;blob-id&gt;</i>] [<i>--type=&lt;type&gt;</i>] [<i>--add</i> | <i>--get</i> | <i>--get-all</i> | <i>--get-regexp=&lt;regexp&gt;</i> | <i>--replace-all</i> | <i>--unset</i> | <i>--unset-all</i> | <i>--rename-section</i> | <i>--remove-section</i> | <i>--list</i> | <i>--edit</i> | <i>--get-color</i> | <i>--get-colorbool</i>] [<i>--name-only</i>] [<i>--null</i>] [<i>&lt;key&gt;</i> [<i>&lt;value&gt;</i> [<i>&lt;value_regexp&gt;</i>]]]


title: PARAMETERS
content:
<b><b>--local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the repository-specific configuration file (<i>.git/config</i>). This is the default when no scope option is given.<br><br><b><b>--global</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the current user's global configuration file (<i>~/.gitconfig</i> on Unix, or <i>%HOMEDRIVE%%HOMEPATH%\.gitconfig</i> on Windows).<br><br><b><b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the system-wide configuration file (<i>$(prefix)/etc/gitconfig</i>).<br><br><b><b>--worktree</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the current worktree's configuration file. Each worktree can have its own specific configuration.<br><br><b><b>-f &lt;file&gt;</b>, <b>--file &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific configuration file instead of the default ones.<br><br><b><b>--get &lt;key&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Get the value for a given key. Only the first value is returned if multiple exist.<br><br><b><b>--set &lt;key&gt; &lt;value&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a new value for a configuration key. If the key already exists, its value is overwritten.<br><br><b><b>--add &lt;key&gt; &lt;value&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a new line to the option, allowing multiple values for a single key. Useful for things like remote URLs.<br><br><b><b>--unset &lt;key&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove the first line matching the given key. Returns an error if no such key exists.<br><br><b><b>--unset-all &lt;key&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove all lines matching the given key. Returns an error if no such key exists.<br><br><b><b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all variables set in the configuration file(s). Can be combined with scope options to filter.<br><br><b><b>--edit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open an editor to manually edit the configuration file of the specified scope (or local by default).<br><br><b><b>--type=&lt;type&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the type of value to be retrieved or set. Can be 'bool', 'int', 'path', 'bool-or-int', 'string'.<br><br><b><b>--name-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>--list</b> or <b>--get-regexp</b>, list only the names of the variables, not their values.<br><br><b><b>--null</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>--list</b> or <b>--get-regexp</b>, terminate output lines with NUL bytes instead of newlines.<br><br>


title: DESCRIPTION
content:
The <b>git config</b> command is a utility that allows users to get and set configuration variables for their Git installations or specific repositories. These variables control virtually every aspect of Git's behavior, from user identity and default editor to merge strategies and alias definitions. It's fundamental for customizing Git to suit individual workflows or project requirements. Users can read individual values, list all settings, or modify existing ones across different scope levels: system-wide, per-user, or specific to a particular repository or even a worktree. This command provides a powerful interface for fine-tuning Git's operations.


title: CAVEATS
content:
Understanding the configuration hierarchy is critical: options from the <i>local</i> level override <i>global</i>, which override <i>system</i>. This cascading behavior means that a setting in your project's <i>.git/config</i> will take precedence over a setting in your <i>~/.gitconfig</i>. Incorrectly configured options can lead to unexpected Git behavior or prevent operations from completing as desired.


title: CONFIGURATION LEVELS
content:
Git reads configuration from multiple files, organized in a hierarchy: <br>1. <b>System-wide</b> (<i>$(prefix)/etc/gitconfig</i>): Applies to all users on the system.<br>2. <b>Global</b> (<i>~/.gitconfig</i> or <i>$XDG_CONFIG_HOME/git/config</i>): Applies to a specific user.<br>3. <b>Repository-local</b> (<i>.git/config</i>): Applies only to the current repository.<br>4. <b>Per-worktree</b> (<i>.git/config</i> within a worktree directory): Applies only to a specific worktree.<br>Settings at lower levels override those at higher levels.


title: VARIABLE NAMING
content:
Configuration variables are typically organized into hierarchical sections and subsections, separated by dots. For example, <i>user.name</i> and <i>core.editor</i>. Section names are often followed by a value in quotes, e.g., <i>[user]<br>&nbsp;&nbsp;name = John Doe</i>. The command line often uses the full dot-separated path, like <i>user.name</i>, for simplicity.


title: HISTORY
content:
<b>git-config</b> has been a core component of Git since its early days, providing the primary interface for managing Git's myriad of configurable options. Over time, its capabilities have expanded, notably with the introduction of per-worktree configuration in Git 2.15, allowing even finer-grained control over multi-worktree setups. Its fundamental design remains consistent, reflecting Git's philosophy of being highly customizable.


title: SYNOPSIS
content:
<b>git-count</b> [<i>--commits</i> | <i>--authors</i> | <i>--lines</i> | <i>--branches</i> | <i>--tags</i> | <i>--files</i> | <i>--all</i>] [<i>--since=<date></i>] [<i>--until=<date></i>] [<i>--branch=<name></i>]


title: PARAMETERS
content:
<b><i>--commits</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts the total number of commits in the specified scope (e.g., branch or date range).<br><br><b><i>--authors</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts the number of unique authors (contributors) in the repository or specified scope.<br><br><b><i>--lines</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts the total lines of code (LOC) for tracked files in the repository or specified scope. This often excludes binary files.<br><br><b><i>--branches</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts the number of local branches in the repository.<br><br><b><i>--tags</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts the number of tags in the repository.<br><br><b><i>--files</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts the total number of tracked files in the repository.<br><br><b><i>--since=<date></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters counts to include only activity (e.g., commits, lines) after the specified date. Date formats vary by implementation but often include 'YYYY-MM-DD', 'N.days.ago'.<br><br><b><i>--until=<date></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters counts to include only activity (e.g., commits, lines) before the specified date.<br><br><b><i>--branch=<name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular branch to analyze instead of the current branch or all branches.<br><br><b><i>--all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all available quantitative metrics (e.g., commits, authors, lines, branches, tags, files).<br><br>


title: DESCRIPTION
content:
The <i>git-count</i> command is typically a user-defined script or alias, not a standard part of the core Git distribution. Its primary purpose is to provide various quantitative insights into a Git repository. Common uses include counting the total number of commits, individual lines of code (LOC) across the repository, active contributors, or specific object types like branches or tags. <br><br>While not universally present, implementations often leverage core Git commands such as <i>git log</i>, <i>git rev-list</i>, <i>git shortlog</i>, or <i>git ls-files</i> combined with shell utilities like <i>wc</i> and <i>awk</i> to extract and process the desired metrics. It serves as a convenient tool for project managers, developers, or anyone needing quick statistics on repository activity and growth.


title: CAVEATS
content:
The <i>git-count</i> command is not part of the standard Git distribution and must be separately installed or created as a custom script or alias. Its exact functionality, options, and output will vary significantly depending on its specific implementation. Users should consult the source code or documentation of their particular <i>git-count</i> script for accurate usage details. Counting lines of code (LOC) can be complex and might not accurately reflect active code if it includes generated files or excludes certain file types.


title: IMPLEMENTATION DETAILS
content:
Custom <i>git-count</i> scripts often combine multiple Git commands. For example, counting commits might use <i>git rev-list --count HEAD</i>, unique authors might use <i>git shortlog -s -n --all | wc -l</i>, and lines of code might involve <i>git ls-files -z | xargs -0 git cat-file blob | wc -l</i> or more sophisticated tools for accurate LOC measurement. The exact logic depends on the script's creator.


title: COMMON USE CASES
content:
Used for quick project health checks, tracking repository growth over time, generating statistics for project reports, and sometimes integrated into continuous integration pipelines to monitor code contributions and activity.


title: HISTORY
content:
As <i>git-count</i> is typically a custom script, it does not have a formal history like core Git commands. Its development is decentralized, arising from individual developers' and teams' needs to quickly gain repository insights. The concept emerged naturally alongside Git's increasing adoption, as users sought to automate reporting on project metrics. Various open-source implementations exist across GitHub and other platforms, showcasing different approaches to achieving similar counting functionalities. Its usage is prevalent in scenarios requiring quick repository audits, project health checks, or CI/CD pipelines to track growth.


title: PARAMETERS
content:
<b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report the number of loose objects found and their total disk usage. Without this option, only the total disk usage is printed.<br><br><b><b>-H</b>, <b>--human-readable</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display disk usage in human-readable units (e.g., KB, MB, GB). This option implies <b>--verbose</b> if <b>--verbose</b> is not specified.<br><br>


title: DESCRIPTION
content:
<i>git count-objects</i> is a Git plumbing command used to report the number and disk consumption of <i>loose</i> objects in the repository's object database. It specifically counts objects that are not yet packed into packfiles. This command is helpful for understanding the state of your repository's object storage and can indicate whether a garbage collection (<i>git gc</i>) might be beneficial to optimize disk space. By default, it outputs the total size of loose objects in bytes. The command does not process objects stored within pack files, focusing solely on the individual files residing directly in the <i>.git/objects</i> directory. It's a quick way to assess the "unpacked" overhead.


title: CAVEATS
content:
This command only counts <i>loose</i> objects (individual files in <i>.git/objects</i>). It does <i>not</i> count objects that are already stored inside pack files. The reported disk usage might slightly differ from direct file system tools like <i>du</i> due to variations in file system block allocation or sparse file handling.


title: HISTORY
content:
<i>git-count-objects</i> has been a part of Git since its early days, serving as a fundamental plumbing command to inspect the object database. Its purpose has remained consistent: to provide a quick overview of the loose object store, aiding in repository maintenance and optimization efforts, particularly in conjunction with garbage collection routines.


title: SYNOPSIS
content:
<I>Non-standard command; behavior depends on user implementation.</I><br><br><I>Typical alias/script usage:</I><br><I><b>git-cp</b> <I>SOURCE</I> <I>DESTINATION</I></I><br><I><b>git-cp</b> <I>[OPTIONS]</I> <I>SOURCE...</I> <I>DIRECTORY</I></I>


title: PARAMETERS
content:
<b><I>SOURCE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the original file or directory to be copied.<br><br><b><I>DESTINATION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path where the copy should be created. Can be a new filename or a directory.<br><br><b><I>-f</I>, <I>--force</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Optional.</I> If implemented, forces overwriting of existing destination files without prompting. This behavior typically relies on the underlying 'cp' command.<br><br><b><I>-r</I>, <I>-R</I>, <I>--recursive</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Optional.</I> If implemented, copies directories and their contents recursively. This behavior typically relies on the underlying 'cp' command.<br><br><b><I>-v</I>, <I>--verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Optional.</I> If implemented, explains what is being done, typically by displaying the files being copied. This behavior typically relies on the underlying 'cp' command.<br><br>


title: DESCRIPTION
content:
<I><b>git-cp</b> is <b>not</b> a standard, built-in command in Git.</I><br><br>Unlike <b>git mv</b> which provides a dedicated command for moving or renaming files while tracking their history, Git intentionally does not offer a direct <b>git cp</b> utility. This design choice stems from Git's underlying content-addressable storage model; it tracks file content and changes, not specific file identities across copies. When a file is copied, Git treats the new copy as an entirely new file, even if its content is identical to the original.<br><br>The functionality typically expected from a <b>git-cp</b> command—copying a file and then immediately staging the new copy for inclusion in the Git repository—is usually achieved by executing two separate commands: first, the operating system's standard <b>cp</b> command to duplicate the file, and then <b>git add</b> to add the newly created file to Git's staging area. Many users create custom aliases or scripts named <b>git-cp</b> to automate this two-step process for convenience. These custom implementations might vary widely in their exact options and behaviors.


title: CAVEATS
content:
<br><I>The most significant caveat is that <b>git-cp</b> is <b>not a built-in Git command</b>. Its existence and behavior are entirely dependent on user or system administrator custom implementations (e.g., as a shell alias or script).</I><br><br><I>Therefore:</I><br><I>- It might not exist on your system.</I><br><I>- If it does exist, its exact functionality, supported options, and error handling can vary significantly.</I><br><I>- It typically involves two steps: first an OS-level file copy (`cp`), then Git staging (`git add`). If the `cp` fails, `git add` might operate on an incomplete or non-existent file.</I><br><I>- Git itself does not inherently track file copies as such. When you copy a file, Git treats the new file as entirely separate. History of the original file is not automatically transferred to the copy.</I>


title: WHY GIT DOES NOT HAVE A GIT CP COMMAND
content:
<br><I>Git's core strength lies in its content-addressable nature. Every piece of content (blob) and directory structure (tree) is identified by its SHA-1 hash. When you copy a file, even if the content is identical, Git treats it as a new path in the repository's tree object. It doesn't store a direct "copied from" relationship. This approach simplifies the internal data model and avoids potential complexities associated with tracking explicit copy histories across branches and merges.</I><br><br><I>While <b>git mv</b> exists, it doesn't "move" the file in Git's internal storage. It simply records that a file was removed from one path and an identical (or very similar) file was added at another path in the same commit. Tools like <b>git diff</b> and <b>git log</b> then have algorithms to detect renames and copies by analyzing content similarity between commits.</I><br><br><I>This philosophy encourages users to use the standard operating system <b>cp</b> command for copying files, followed by <b>git add</b> for staging the new file, which aligns with Git's focus on managing the <i>state</i> of the working directory and index rather than directly manipulating historical relationships for copies at the command line.</I>


title: HISTORY
content:
<br><I>From its inception, Git's design philosophy has emphasized tracking content rather than direct file identity, particularly for operations like copying. Unlike some other version control systems (e.g., SVN), Git does not have a dedicated "copy" command that preserves a direct historical link between an original file and its copy.</I><br><br><I>Instead, Git internally identifies copied files by their content similarity. When a file is copied and added to the repository, Git simply sees a new file. Later, if necessary (e.g., during <b>git blame</b> or <b>git log --follow</b>), Git can intelligently detect a copy based on content similarity, but this is an analytical feature rather than a direct command-driven history link.</I><br><br><I>Because of this design, a standard <b>git cp</b> command was never included in the core Git distribution. The functionality for copying and staging is delegated to existing operating system tools (<b>cp</b>) combined with Git's staging mechanism (<b>git add</b>). Users who desire a single <b>git cp</b> command typically implement it themselves as a shell alias or a small wrapper script.</I>


title: PARAMETERS
content:
<b><I>new_branch_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired name for the new branch. Branch names should be descriptive and typically don't contain spaces or certain special characters (e.g., '/', '~', '^', ':', '?', '*').<br><br><b>[<I>start_point</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument specifying the commit ID, tag, or existing branch from which the new branch will originate. If omitted, the new branch will point to the current <i>HEAD</i> (the commit you are currently checked out on).<br><br><b>--track, -t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets up 'tracking' information. This means the new local branch will automatically track an upstream branch (e.g., a remote branch) of the same name if one exists. This is commonly used when creating a local branch from a remote one, like <i>git branch --track my_feature origin/my_feature</i>.<br><br><b>--no-track</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default behavior of setting up tracking if it would otherwise be implied (e.g., when creating a local branch with the same name as a remote one from a remote tracking branch).<br><br><b>--force, -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If a branch with <I>new_branch_name</I> already exists, Git will forcefully move it to the <I>start_point</I>, discarding its previous history. Use with extreme caution, as this can lead to loss of work if the existing branch contained unmerged commits.<br><br>


title: DESCRIPTION
content:
The <i>git branch</i> command is fundamental to Git's branching model, allowing users to create, list, rename, and delete branches. In Git, a branch is simply a lightweight, movable pointer to one of the commits in your repository's history. When you create a new branch, Git creates a new pointer at the current commit you're on, allowing you to diverge your work, develop new features, or fix bugs without affecting the main codebase.<br><br>While the query references "git-create-branch," it's important to note that this is <b>not</b> a standard Git command. The correct and widely used command for creating branches is <i>git branch</i>. It's possible that "git-create-branch" might be a custom alias, a wrapper script, or a misunderstanding of the standard command's usage. This analysis focuses on the standard <i>git branch</i> command and its branch creation capabilities.


title: CAVEATS
content:
The command 'git-create-branch' is <b>not</b> a standard Git command. The information provided here pertains to the standard 'git branch' command.<br><br>Creating a branch only creates a pointer; it does not automatically switch your working directory to that branch. To move to the newly created branch, you must explicitly use <i>git checkout new_branch_name</i> or <i>git switch new_branch_name</i>.<br><br>Branch names cannot contain control characters, space, tilde (~), caret (^), colon (:), question mark (?), asterisk (*), or open square bracket ([). It's also best practice to avoid backslashes (\) and leading/trailing slashes in branch names.


title: GIT'S BRANCHING PHILOSOPHY
content:
Unlike traditional version control systems where branches might be heavy, isolated copies of the codebase, Git branches are incredibly lightweight pointers. This design encourages developers to create branches frequently for small, isolated tasks, promoting a highly flexible and non-linear development workflow.


title: THE `GIT-<COMMAND>` PATTERN
content:
Git commands often follow a pattern where <i>git</i> looks for an executable named <i>git-<command></i> (e.g., <i>git-branch</i>, <i>git-checkout</i>) in your system's PATH. This design allows for easy extension of Git's capabilities through custom scripts or aliases, which might explain why a user might encounter a non-standard command like 'git-create-branch' if it's a locally defined helper.


title: HISTORY
content:
Git was created by Linus Torvalds in 2005 for Linux kernel development, primarily to handle distributed development efficiently. Its core strength lies in its robust and cheap branching model, which was a significant departure from older version control systems. The <i>git branch</i> command has been a fundamental part of Git since its inception, embodying the lightweight pointer concept that makes branching and merging so flexible and commonplace in Git workflows.


title: TLDR
content:
<b>Open a file with the default application (e.g. PDF, image)</b>`gio open [path/to/file]`<br><b>List files in a directory</b>`gio list [path/to/directory]`<br><b>Show information about a file</b>`gio info [path/to/file]`<br><b>Copy a file</b>`gio copy [path/to/source] [path/to/destination]`<br><b>Send a file to the trash (reversible)</b>`gio trash [path/to/file]`


title: TLDR
content:
<b>Run a command as if the machine architecture is i686 (useful for running 32-bit apps on a 64-bit kernel)</b>`setarch i686 [command]`<br><b>Run a shell with the x86_64 architecture</b>`setarch x86_64 [bash]`<br><b>Disable randomization of the virtual address space</b>`setarch [linux32] [[-R|--addr-no-randomize]] [command]`<br><b>List supported architectures</b>`setarch --list`<br><b>Display help</b>`setarch [[-h|--help]]`


title: TLDR
content:
<b>Display all devices detected by fwupd</b>`fwupdtool get-devices`<br><b>Install firmware from a file</b>`fwupdtool install [path/to/firmware]`<br><b>Display help</b>`fwupdtool [[-h|--help]]`


title: TLDR
content:
<b>Select the soundcard to use</b>`alsamixer [[-c|--card]] [soundcard_number]`<br><b>Select mixer device to control</b>`alsamixer [[-D|--device]] [device_name]`<br><b>Increase volume</b>`<w>`<br><b>Decrease volume</b>`<x>`<br><b>Quit alsamixer</b>`<Esc>`


title: PARAMETERS
content:
<b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the generation of a new system key, overwriting any existing key in the keystore without prompting for confirmation. Use with caution as it will invalidate previously encrypted data if not handled properly.<br><br><b>--path.conf <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Elasticsearch configuration directory (e.g., /etc/elasticsearch). This tells the command where to locate or create the Elasticsearch keystore. If not specified, the command will attempt to use default locations or environment variables.<br><br>


title: DESCRIPTION
content:
<I>The <B>elasticsearch-syskeygen</B> command is a utility provided with Elasticsearch to generate a system key. This key is crucial for enhancing the security of your Elasticsearch cluster by encrypting sensitive information stored within the Elasticsearch keystore. It ensures that sensitive settings, such as passwords for realms or repository credentials, are stored securely on disk. When this command is executed, it creates a new system key, stores it in the configured Elasticsearch keystore, and marks it for use in encrypting future entries or decrypting existing ones. The system key is essential for features like built-in security and encrypted settings in the keystore. Without a valid system key, certain security features might not function correctly, and sensitive data could be less protected.</I>


title: CAVEATS
content:
<I>The system key is highly sensitive. Losing or compromising this key can render encrypted data in your Elasticsearch keystore inaccessible or vulnerable. Always ensure proper filesystem permissions are set on the keystore and the system key file, typically allowing read/write only to the Elasticsearch user. It is critical to back up your system key in a secure, offline location. This key is typically node-specific; ensure consistency if managing multiple nodes manually in a cluster where shared encrypted settings are used.</I>


title: KEYSTORE INTERACTION
content:
<I>The <B>elasticsearch-syskeygen</B> command implicitly interacts with the Elasticsearch keystore. Before generating a key, ensure the keystore is initialized (e.g., using <B>elasticsearch-keystore create</B>). The system key is stored within this keystore, protecting sensitive data such as realm passwords and secure settings.</I>


title: BACKUP IMPORTANCE
content:
<I>It is paramount to back up the generated system key. While the command places it in the keystore, having a secure, offline backup is crucial for disaster recovery. Without it, recovering encrypted data after a system failure or accidental keystore corruption would be impossible.</I>


title: PERMISSIONS
content:
<I>Ensure that the user running the <B>elasticsearch-syskeygen</B> command has appropriate read and write permissions to the Elasticsearch configuration directory and the keystore file. Incorrect permissions can prevent the key from being generated or properly stored, leading to security and operational issues.</I>


title: HISTORY
content:
<I>The system key feature was introduced in Elasticsearch primarily to enhance security by allowing encryption of sensitive settings within the Elasticsearch keystore, alongside the broader development of X-Pack security features. Its purpose evolved as Elasticsearch's security capabilities matured, providing a more robust mechanism for protecting credentials and other confidential data stored on disk. This command streamlines the process of generating this vital security component.</I>


title: TLDR
content:
<b>Generate the system_key file in the default $ES_HOME/config directory</b>`elasticsearch-syskeygen`


title: PARAMETERS
content:
<b><I>shareName</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the SMB share that will be advertised to clients (e.g., 'SHARE', 'C$').<br><br><b><I>sharePath</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The local path to the directory that will be exposed as the SMB share.<br><br><b>-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output, useful for troubleshooting connection or authentication issues.<br><br><b>-smb2support</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables support for the SMB2 protocol, allowing newer clients to connect using SMB2.<br><br><b>-comment <I>COMMENT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a comment for the SMB share, visible to clients browsing available shares.<br><br><b>-no-smb-negotiate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables SMB dialect negotiation, forcing the server to accept a specific SMB version (usually SMB1).<br><br><b>-no-smb-challenge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the server from sending an NTLM challenge, often used in specific relay scenarios or to prevent hash capture.<br><br><b>-no-smb-encryption</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables enforcement of SMB encryption, allowing unencrypted connections. By default, encryption is enforced if supported by the client and server.<br><br><b>-no-smb-signing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables enforcement of SMB signing, allowing unsigned connections. By default, signing is enforced if supported by the client and server.<br><br><b>-username <I>USERNAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a username for required authentication. If not set, anonymous access might be allowed depending on other options.<br><br><b>-password <I>PASSWORD</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a password for the provided username for required authentication.<br><br><b>-aesKey <I>AESKEY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the AES key for Kerberos authentication. Typically used in more advanced scenarios involving Kerberos.<br><br><b>-hashes <I>LMHASH:NTHASH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides LM and NT hashes for authentication instead of a plain-text password. Format is LMhash:NThash (e.g., 'aad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0').<br><br><b>-port <I>PORT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the TCP port on which the SMB server will listen. Default is 445.<br><br><b>-no-smb-share-create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents clients from creating new shares on the server (e.g., if a client attempts to create an 'ADMIN$' share).<br><br>


title: DESCRIPTION
content:
The <b>smbserver.py</b> command, part of the <I>Impacket</I> toolkit, is a versatile Python-based implementation of an SMB/CIFS server. Unlike traditional SMB servers like Samba, <b>smbserver.py</b> is designed with a focus on penetration testing and security auditing. It allows users to quickly set up an SMB share from a specified local directory, facilitating file transfers, or more commonly, acting as a honeypot to capture NTLMv1/v2 hashes from connecting clients. <br><br>Its lightweight nature and programmatic control make it an ideal tool for scenarios like: serving payloads to compromised systems, collecting authentication material (hashes) from vulnerable clients, or acting as a relay target in NTLM relay attacks. It supports various SMB versions, including SMB2, and offers options for controlling authentication requirements, signing, and encryption, making it highly configurable for different testing environments.


title: CAVEATS
content:
Running <b>smbserver.py</b> on standard ports (like 445) often requires root or elevated privileges.<br>Exposing file shares can be a security risk if not done carefully, potentially exposing sensitive files or allowing unauthorized file uploads.<br>When used for hash capturing, be aware that NTLMv1/v2 hashes are vulnerable to offline brute-force attacks if captured. Ensure proper controls are in place.<br>This tool is primarily for security testing and should not be used as a production-grade SMB server.


title: HISTORY
content:
<b>smbserver.py</b> is a core component of the <I>Impacket</I> library, a collection of Python classes developed by Core Security Technologies (now Fortra) for programmatic access to network protocols. <I>Impacket</I> and its tools, including <b>smbserver.py</b>, have evolved significantly over the years to adapt to new protocol versions (like SMB2/3) and emerging attack techniques, becoming a de-facto standard in network penetration testing and red team operations due to its flexibility and comprehensive protocol implementation.


title: TLDR
content:
<b>Set up a basic SMB share</b>`smbserver.py [sharename] [path/to/share]`<br><b>Set up a share with a custom comment</b>`smbserver.py -comment [my_share] [sharename] [path/to/share]`<br><b>Set up a share with username and password authentication</b>`smbserver.py -username [username] -password [password] [sharename] [path/to/share]`<br><b>Set up a share with NTLM hash authentication</b>`smbserver.py -hashes [LMHASH]:[NTHASH] [sharename] [path/to/share]`<br><b>Set up a share on a specific interface</b>`smbserver.py [[-ip|--interface-address]] [interface_ip_address] [sharename] [path/to/share]`<br><b>Set up a share on a non-standard SMB port</b>`smbserver.py -port [port] [sharename] [path/to/share]`<br><b>Set up a share with SMB2 support</b>`smbserver.py -smb2support [sharename] [path/to/share]`<br><b>Set up a share and log commands to an output file</b>`smbserver.py -outputfile [path/to/output_file] [sharename] [path/to/share]`


title: PARAMETERS
content:
<b><i>&lt;share_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The arbitrary name to assign to the SMB share that will be advertised to clients (e.g., 'SHARE', 'C$').<br><br><b><i>&lt;share_path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The local path to the directory that the SMB server will share. This directory's contents will be accessible (or appear to be accessible) to connecting clients.<br><br><b>-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output, useful for troubleshooting connection issues or understanding server behavior.<br><br><b>-smb2support</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables SMB2 protocol support. It is highly recommended to use this option for compatibility with modern Windows clients, which primarily use SMB2/3.<br><br><b>-username <i>&lt;username&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a username for authenticated access to the share. If omitted, anonymous access is typically allowed or prompted depending on the client.<br><br><b>-password <i>&lt;password&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the password for the provided <i>-username</i>. Used in conjunction with <i>-username</i> for creating an authenticated share.<br><br><b>-hashes <i>&lt;LM:NT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides LM and NT hashes (e.g., '0:f34ad...'). This is an alternative to <i>-password</i>, allowing authentication using pre-computed hashes.<br><br><b>-target-ip <i>&lt;ip_address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the IP address of the interface on which the server should listen. By default, it listens on all available interfaces (0.0.0.0).<br><br><b>-ipv6</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the server to listen for incoming connections over IPv6 instead of IPv4.<br><br><b>-no-smb-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the server from loading a default or existing smb.conf file, ensuring a clean, minimal server setup.<br><br><b>-no-netlogon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the NETLOGON share. This share is typically used by domain controllers for user authentication, and disabling it can reduce network noise if not needed.<br><br><b>-no-nbt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables NetBIOS over TCP/IP (NetBT) services. This means the server will only listen on port 445 (SMB direct) and not on NetBIOS ports like 137/138/139.<br><br><b>-port <i>&lt;port_number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the TCP port number on which the SMB server will listen. The default SMB port is 445. Using a different port may require client configuration.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables quiet mode, suppressing most output to the console, useful for backgrounding or scripting.<br><br>


title: DESCRIPTION
content:
The <i>impacket-smbserver</i> command, part of the powerful <i>Impacket</i> toolkit, creates a minimalistic yet functional SMB (Server Message Block) server. Its primary purpose is to serve files over SMB/CIFS, but it's most renowned for its ability to capture NTLMv1/v2 authentication hashes from connecting clients. This makes it an invaluable tool for penetration testers and red teamers to simulate malicious servers, conduct credential harvesting, or facilitate file transfers in environments where SMB is prevalent. It supports both anonymous and authenticated access, and can be configured to listen on specific interfaces and ports, providing flexibility for various network scenarios.


title: CAVEATS
content:
<b>Root Privileges:</b> To bind to the default SMB port (445), <i>impacket-smbserver</i> typically requires root or elevated privileges.<br><b>Security Implications:</b> This tool is frequently used for credential harvesting and can be misused. Ensure you have proper authorization for its use.<br><b>Firewall Rules:</b> Ensure that your system's firewall allows inbound connections on the specified SMB port (default 445) for clients to connect.<br><b>Antivirus/EDR Detection:</b> Due to its common use in penetration testing, many security solutions might flag <i>impacket-smbserver</i> as a malicious tool.


title: COMMON USE CASES
content:
<b>NTLM Hash Capture:</b> Set up a share and wait for clients to connect (e.g., from network scanners, misconfigured applications, or phishing attempts) to capture NTLMv1/v2 authentication hashes which can then be cracked offline.<br><b>File Transfer:</b> Serve or receive files in environments where HTTP/FTP might be blocked, but SMB is open. This is useful for transferring payloads or exfiltrating data.<br><b>Anonymous File Sharing:</b> Create quick, anonymous shares for testing or temporary file access without needing full-fledged SMB server configuration.<br><b>SMB Relay Attacks:</b> While <i>impacket-smbserver</i> itself doesn't perform the relay, it's often used in conjunction with tools like <i>ntlmrelayx.py</i> (also from Impacket) as the target server for relayed authentication attempts.


title: AUTHENTICATION BEHAVIOR
content:
By default, <i>impacket-smbserver</i> attempts to handle anonymous authentication. If a client attempts to authenticate, it captures the NTLM hash. You can specify a username and password (or hashes) to allow specific authenticated access. If a client provides valid credentials that match what's configured, access is granted; otherwise, the hashes are captured, and the connection might be closed or denied based on client behavior.


title: HISTORY
content:
<i>Impacket</i> is a collection of Python classes for working with network protocols, primarily developed by Alberto Solino (corelabs.org, now Fortra's Core Security). It focuses on providing programmatic access to network packets and various Windows protocols (like SMB, MSRPC, DCE/RPC, Kerberos). The <i>smbserver.py</i> module (accessible via <i>impacket-smbserver</i>) emerged as a critical component, enabling penetration testers and researchers to interact with SMB in a controlled manner, filling a significant gap in open-source tooling for Windows network protocol exploitation and analysis. Its development reflects the continuous need for robust tools to assess and exploit vulnerabilities in Windows environments.


title: TLDR
content:
<b>Connect to an SMB server with username and password</b>`smbclient.py [domain]/[username]:[password]@[target]`<br><b>Connect using NTLM hashes for authentication</b>`smbclient.py -hashes [LM_HASH]:[NT_HASH] [domain]/[username]@[target]`<br><b>Connect using Kerberos authentication</b>`smbclient.py -k [domain]/[username]@[target]`<br><b>Connect specifying a domain controller IP</b>`smbclient.py -dc-ip [domain_controller_ip] [domain]/[username]:[password]@[target]`<br><b>Connect to a specific target IP instead of NetBIOS name</b>`smbclient.py -target-ip [target_ip] [domain]/[username]:[password]@[target]`<br><b>Connect to a non-standard SMB port</b>`smbclient.py -port [port] [domain]/[username]:[password]@[target]`<br><b>Execute commands from an input file in the SMB shell</b>`smbclient.py -inputfile [path/to/input_file] [domain]/[username]:[password]@[target]`<br><b>Log SMB client commands to an output file</b>`smbclient.py -outputfile [path/to/output_file] [domain]/[username]:[password]@[target]`


title: SYNOPSIS
content:
<b>To view documentation:</b><br>`<b>man ffmpeg-devices</b>`<br><br><b>To use devices with FFmpeg:</b><br>The `ffmpeg-devices` manual describes the device formats utilized by the core `ffmpeg` command. When interacting with devices, `ffmpeg` employs the `<i>-f</i>` option to specify the device format, followed by the `<i>-i</i>` option and the device path or identifier.<br><br><i>General Usage Pattern:</i><br>`<b>ffmpeg -f </b><i>&lt;device_format&gt;</i><b> [</b><i>device_options</i><b>] -i </b><i>&lt;device_path_or_id&gt;</i><b> [</b><i>output_options</i><b>] </b><i>&lt;output_file_or_device&gt;</i>`<br><br><i>Examples:</i><br>`<b>ffmpeg -f v4l2 -framerate 30 -video_size 640x480 -i /dev/video0 output.mkv</b>`<br>`<b>ffmpeg -f alsa -i hw:0,0 audio.wav</b>`<br>`<b>ffmpeg -f x11grab -framerate 25 -video_size 1920x1080 -i :0.0+0,0 desktop.mp4</b>`


title: PARAMETERS
content:
<b>v4l2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Linux Video4Linux2 input device for webcams, capture cards. Common options include: `<i>-video_size Wxh</i>` (e.g., 640x480), `<i>-framerate N</i>`, `<i>-input_format fmt</i>`, `<i>-standard std</i>`.<br><br><b>alsa</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Advanced Linux Sound Architecture input/output device. Common options include: `<i>-channels N</i>`, `<i>-sample_rate N</i>`, `<i>-f s16le</i>` (sample format).<br><br><b>x11grab</b><br>&nbsp;&nbsp;&nbsp;&nbsp;X11 display screen grabbing device for recording desktop sessions. Common options include: `<i>-video_size Wxh</i>`, `<i>-framerate N</i>`, `<i>-i :0.0+offset_x,offset_y</i>` (offset for capturing a specific part of the screen).<br><br><b>decklink</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Blackmagic Design DeckLink capture/playback device. Common options include: `<i>-video_input N</i>`, `<i>-audio_input N</i>`, `<i>-raw_format fmt</i>`, `<i>-framerate N</i>`.<br><br><b>lavfi</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Libavfilter virtual device. Allows complex filtergraphs to be used as input sources. Options are defined by the specific filtergraph used (e.g., `<i>-i "amovie=input.mp3,asetrate=44100*1.5"</i>`).<br><br><b>pulse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;PulseAudio sound server input/output device. Common options include: `<i>-server addr</i>`, `<i>-device name</i>`.<br><br><b>fbdev</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Linux framebuffer device input for direct screen capture. Common options include: `<i>-framerate N</i>`.<br><br><b>oss</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open Sound System input/output device. Options are generally similar to ALSA but specific to the OSS interface.<br><br>


title: DESCRIPTION
content:
The `ffmpeg-devices` entry refers to the manual page that provides comprehensive documentation on the various input and output devices supported by the FFmpeg multimedia framework. It serves as an essential reference for users who need to capture audio or video from hardware sources, or stream/output data to specific devices.<br><br>This documentation details device-specific formats (e.g., `v4l2`, `alsa`, `x11grab`, `decklink`), their unique options, and how to interact with them using the main `ffmpeg` command-line tool. Understanding `ffmpeg-devices` is crucial for configuring `ffmpeg` for tasks like live streaming, recording from webcams or microphones, or playing audio directly to a sound card.<br><br>It empowers users to leverage FFmpeg's powerful capabilities to interface with a wide range of multimedia hardware, ensuring proper setup and optimal performance for capture and playback operations across different operating systems.


title: CAVEATS
content:
<b>Compilation Dependency:</b> Support for specific devices (e.g., DeckLink, PulseAudio) depends heavily on how your FFmpeg binary was compiled. If FFmpeg was built without certain libraries, the corresponding device formats will not be available. You can check compiled-in support with `<b>ffmpeg -devices</b>`.<br><br><b>System Drivers & Permissions:</b> Proper functioning of devices requires correct kernel modules/drivers to be loaded and appropriate user permissions (e.g., belonging to `video` or `audio` groups) to access device files (`/dev/videoX`, `/dev/snd/pcmC0D0p`).<br><br><b>Device-Specific Complexity:</b> Each device format has its own set of unique options, which can be complex and require detailed understanding of the hardware capabilities and limitations. Referencing the `ffmpeg-devices` man page is crucial for proper configuration.<br><br><b>Platform Specificity:</b> Many devices are platform-specific (e.g., `v4l2`, `alsa`, `fbdev` are Linux-specific; `dshow` is Windows-specific; `avfoundation` is macOS-specific). The `ffmpeg-devices` manual often includes information relevant to various operating systems where applicable.


title: LISTING AVAILABLE DEVICES
content:
To see which device formats your FFmpeg binary supports, use the `<b>-devices</b>` option with the main `<b>ffmpeg</b>` command: <br>`<b>ffmpeg -devices</b>` <br>This command will list all compiled-in input and output device formats. To identify specific hardware devices on your system (e.g., webcam paths, audio device IDs), you might need system-specific utilities like `<b>ls /dev/video*</b>`, `<b>aplay -L</b>`, or `<b>arecord -L</b>`.


title: INPUT VS. OUTPUT DEVICES
content:
The `ffmpeg-devices` manual often distinguishes between input devices (used with `<b>-i</b>` for capture) and output devices (used as the final argument for playback/streaming). While many devices can function as both (e.g., ALSA), some are typically input-only (e.g., `<b>v4l2</b>`, `<b>x11grab</b>`). Understanding this distinction is key to constructing correct `<b>ffmpeg</b>` commands for your desired operation.


title: HISTORY
content:
FFmpeg, initiated by Fabrice Bellard in 2000, has evolved into a cornerstone of multimedia processing. Device support has been an integral part of its development, enabling direct interaction with hardware for capture and playback. Early versions focused on basic video and audio input/output, primarily through standard Linux interfaces like V4L and OSS. Over time, support expanded significantly to include more advanced and specific hardware (e.g., ALSA, PulseAudio, DeckLink, various capture cards) and platform-specific APIs (DirectShow on Windows, AVFoundation on macOS). The `ffmpeg-devices` manual page itself serves as a continuously updated catalog reflecting this ongoing evolution, ensuring that FFmpeg remains a versatile tool for both generic and specialized hardware multimedia tasks.


title: SYNOPSIS
content:
<b>ffplay</b> [<i>options</i>] [<i>input_url</i>]<br><br><i>ffplay</i> usually takes one input URL or file path. Options can precede or follow the input.


title: PARAMETERS
content:
<b><b>-i <i>input_url</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file or URL. Often optional, as the first non-option argument is taken as input.<br><br><b><b>-fs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Toggles full screen playback.<br><br><b><b>-an</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables audio playback.<br><br><b><b>-vn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables video playback.<br><br><b><b>-ss <i>position</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Seeks to <i>position</i> (in seconds or H:M:S[.milli]) from the start of the input.<br><br><b><b>-t <i>duration</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays for a maximum <i>duration</i> (in seconds or H:M:S[.milli]).<br><br><b><b>-loop <i>count</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loops playback <i>count</i> times. 0 for infinite loop.<br><br><b><b>-vf <i>filter_graph</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a video filter graph (e.g., `crop=1280:720`, `scale=640:-1`).<br><br><b><b>-af <i>filter_graph</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies an audio filter graph (e.g., `volume=0.5`, `equalizer=f=1000:g=10`).<br><br><b><b>-window_title <i>title</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the window title of the player.<br><br><b><b>-x <i>width</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial video window width.<br><br><b><b>-y <i>height</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial video window height.<br><br><b><b>-noborder</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables window borders for the video display.<br><br><b><b>-autoexit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits automatically when playback finishes.<br><br><b><b>-volume <i>volume</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial audio volume (0 to 100).<br><br><b><b>-stats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows playback statistics (fps, bitrate, etc.) on the console.<br><br><b><b>-sync <i>type</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the master clock synchronization source (e.g., `audio`, `video`, `external`). Default is `audio`.<br><br><b><b>-loglevel <i>level</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the logging level for console output. Common levels include `info`, `warning`, `error`, `verbose`, `debug`.<br><br><b><b>-hide_banner</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses printing the FFmpeg banner information on startup.<br><br>


title: DESCRIPTION
content:
<i>ffplay</i> is a simple, portable media player that uses the FFmpeg libraries (libavformat, libavcodec, libavutil, libswresample, libswscale, and libpostproc) to play virtually any media file or stream that FFmpeg can decode. While not a full-featured media player with an extensive graphical user interface, <i>ffplay</i> excels as a quick and efficient tool for testing FFmpeg features, debugging codecs, verifying streams, or simply for quick playback of media files from the command line. It supports a vast array of audio and video formats, including network streams, and allows for real-time application of audio and video filters. Its minimalist design prioritizes speed and direct interaction with FFmpeg's core capabilities, making it an invaluable tool for developers, media professionals, and power users who need to inspect or play media content without the overhead of a larger application.


title: CAVEATS
content:
<i>ffplay</i> is not intended as a replacement for full-featured media players like VLC or MPV. Its graphical user interface is minimal, relying heavily on keyboard shortcuts for controls. While powerful for its intended purpose of testing and quick viewing, it may lack advanced playback features, extensive playlist management, or comprehensive error recovery present in dedicated consumer media players. It also requires FFmpeg libraries to be installed.


title: <B>KEYBOARD CONTROLS</B>
content:
<i>ffplay</i> relies on a set of simple keyboard shortcuts for interactive control during playback:<br><b>q</b> or <b>ESC</b>: Quit playback.<br><b>f</b>: Toggle full screen.<br><b>p</b> or <b>SPACE</b>: Pause/resume playback.<br><b>m</b>: Toggle mute.<br><b>9</b> / <b>0</b>: Decrease/increase volume.<br><b>LEFT</b> / <b>RIGHT</b>: Seek backward/forward by 10 seconds.<br><b>DOWN</b> / <b>UP</b>: Seek backward/forward by 1 minute.<br><b>s</b>: Step forward one frame (when paused).<br><b>a</b>: Cycle through available audio streams.<br><b>v</b>: Cycle through available video streams.<br><b>t</b>: Cycle through available subtitle streams.<br><b>w</b>: Show audio waves.<br><b>c</b>: Show video component colors.<br><b>z</b>: Show stream information (codec, fps, bitrate).<br><b>h</b>: Show help overlay with key bindings.


title: HISTORY
content:
<i>ffplay</i> has been an integral part of the FFmpeg project since its early stages. Developed primarily by FFmpeg's core contributors, it serves as a lightweight, command-line-driven player built directly upon the same powerful decoding and filtering libraries that power <i>ffmpeg</i> and <i>ffprobe</i>. Its evolution mirrors that of the FFmpeg project itself, continuously gaining support for new codecs, formats, and filtering capabilities. It remains a key tool for developers and users needing a direct interface to FFmpeg's playback functionalities without the overhead of a complex GUI.


title: SYNOPSIS
content:
<b>ffsend</b> <i>[OPTIONS] <FILE...></i><br><b>ffsend</b> <i>receive [OPTIONS] <URL></i><br><b>ffsend</b> <i>delete [OPTIONS] <URL></i><br><b>ffsend</b> <i>info [OPTIONS] <URL></i>


title: PARAMETERS
content:
<b><b>-s</b>, <b>--server</b> <i><URL></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom Send server URL to use instead of the default.<br><br><b><b>-t</b>, <b>--time</b> <i><DURATION></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the file expiration time (e.g., <i>1h</i> for 1 hour, <i>1d</i> for 1 day, <i>5m</i> for 5 minutes). Maximum values depend on the server.<br><br><b><b>-l</b>, <b>--downloads</b> <i><COUNT></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of times the file can be downloaded before it expires.<br><br><b><b>-p</b>, <b>--password</b> <i><PASSWORD></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Password protect the uploaded file. This password is required for anyone attempting to download the file.<br><br><b><b>-m</b>, <b>--message</b> <i><TEXT></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a custom message that will be displayed to the recipient when they access the download link.<br><br><b><b>-i</b>, <b>--incognito</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upload files without storing any metadata on the server. This provides an additional layer of privacy but may prevent some features like download counts.<br><br><b><b>-c</b>, <b>--copy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically copy the generated download URL to your system's clipboard after a successful upload.<br><br><b><b>-o</b>, <b>--output</b> <i><PATH></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output path or filename for a downloaded file. If a directory is specified, the original filename is used.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite existing files during a download without prompting for confirmation.<br><br><b><b>--no-check-certificate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable SSL/TLS certificate verification for the server. Use with caution, as it can expose you to man-in-the-middle attacks.<br><br>


title: DESCRIPTION
content:
<b>ffsend</b> is a robust and user-friendly command-line client for the Firefox Send service (and compatible self-hosted instances). It enables end-to-end encrypted file sharing directly from your terminal. Users can effortlessly upload files, generating a unique, shareable URL. Key features include setting expiration times for shared files, limiting the number of downloads, and protecting uploads with a password for an added layer of security. The client also supports downloading files from existing Send URLs.<br><br>While the official Mozilla Firefox Send service has been discontinued, <b>ffsend</b> remains highly valuable for interacting with self-hosted instances of Firefox Send or other services that implement the same API, ensuring secure and private file transfers without relying on web browsers. It prioritizes privacy and convenience, making it ideal for sharing sensitive data.


title: CAVEATS
content:
The official Mozilla Firefox Send service was discontinued in September 2020 due to misuse. Therefore, <b>ffsend</b> now primarily functions as a client for self-hosted instances of Firefox Send or other third-party servers that implement the same API. Users must ensure the trustworthiness of any Send server they connect to, as the server, while not seeing plaintext data, may still log metadata unless the <b>--incognito</b> option is used.


title: SECURITY CONSIDERATIONS
content:
<b>ffsend</b> provides end-to-end encryption, meaning files are encrypted on your client before being sent and decrypted only on the recipient's side. The server never sees the plaintext data. However, for maximum security, always verify the trustworthiness of the Send server you are using, especially if it's not self-hosted. The server *does* see some metadata like file size, number of downloads, and expiration settings, unless the <b>--incognito</b> option is used.


title: SELF-HOSTING
content:
Given the official service's discontinuation, <b>ffsend</b> is most effectively used in conjunction with a self-hosted instance of Firefox Send. This allows users full control over their file-sharing infrastructure, ensuring privacy and availability independently of third-party services. Documentation for setting up a self-hosted Send instance is available from the original Mozilla Send GitHub repository or community forks.


title: HISTORY
content:
<b>ffsend</b> was developed as a command-line client for the Firefox Send service, which was launched by Mozilla to provide a secure, ephemeral file-sharing platform. The service gained popularity for its end-to-end encryption and time-limited downloads.<br><br>In September 2020, Mozilla officially discontinued the Firefox Send service due to abuse issues, shifting its focus elsewhere. Despite the service's discontinuation, the <b>ffsend</b> client continues to be actively maintained. Its development now primarily focuses on supporting self-hosted instances of Firefox Send (the server-side software is open-source) or other compatible services that implement the same API. This ensures that users who wish to run their own secure file-sharing service can still leverage <b>ffsend</b> for convenient command-line interaction, preserving the original spirit of secure, temporary file sharing.


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays help information for the Firebase CLI itself or for a specified subcommand.</i><br><i>Example: firebase --help or firebase deploy --help</i><br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Outputs the version number of the Firebase CLI currently installed.</i><br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables debug mode, providing more verbose output which can be helpful for troubleshooting issues.</i><br><br><b><b>--project &lt;alias_or_id&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the Firebase project to use for the command. This can be a project ID or an alias defined in your .firebaserc file.</i><br><br><b><b>--token &lt;token&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Authenticates using a specific Firebase access token instead of logging in via the browser. This is particularly useful for CI/CD environments.</i><br><br><b><b>--non-interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Runs the command in non-interactive mode, suppressing prompts and requiring all necessary information to be provided via command-line options or environment variables. Ideal for automated scripts.</i><br><br>


title: DESCRIPTION
content:
The <b>Firebase CLI</b> is a powerful command-line interface provided by Google for interacting with and managing your Firebase projects directly from your local machine. It serves as the primary tool for developers to automate and streamline many common tasks associated with building and deploying Firebase applications. The CLI allows you to perform a wide range of operations, including <br><i>deploying web applications and static assets to Firebase Hosting</i>, <br><i>deploying serverless backend logic to Cloud Functions for Firebase</i>, <br><i>managing Realtime Database and Cloud Firestore data, security rules, and indexes</i>, <br><i>initializing new Firebase projects and linking them to existing ones</i>, and <br><i>emulating various Firebase services (like Hosting, Functions, Firestore, Realtime Database, Authentication, and Pub/Sub) locally during development for faster iteration and testing</i>. <br>It significantly enhances the development workflow for applications built on the Firebase platform, enabling rapid iteration, efficient deployment, and robust local testing capabilities.


title: CAVEATS
content:
<i>The Firebase CLI requires <b>Node.js</b> and <b>npm</b> (Node Package Manager) to be installed on your system for its installation and operation. <br>You must authenticate your CLI with your Google account using <b>firebase login</b> before you can manage your projects. <br>For new projects, an initial setup via <b>firebase init</b> is typically required to configure project settings and create necessary files. <br>Many changes made locally, such as code for Hosting or Functions, require explicit deployment using <b>firebase deploy</b> to be reflected in your live Firebase project. <br>Each subcommand has its own specific set of options and arguments, which can be viewed using the <b>--help</b> flag with that subcommand.</i>


title: <B>KEY SUBCOMMANDS</B>
content:
<i>The Firebase CLI is structured around numerous subcommands, each responsible for a specific aspect of Firebase project management. Some of the most frequently used include:<br><b>firebase init</b>: Sets up a new Firebase project in the current directory, linking it to your remote Firebase project.<br><b>firebase deploy</b>: Deploys your project's code to Firebase Hosting, Cloud Functions, and Realtime Database/Cloud Firestore security rules.<br><b>firebase serve</b>: Serves your Firebase Hosting content locally for testing.<br><b>firebase emulators:start</b>: Starts local emulators for various Firebase services (e.g., Hosting, Functions, Firestore, Realtime Database, Authentication, Pub/Sub) to enable offline development and testing.<br><b>firebase functions:log</b>: Displays recent logs for your Cloud Functions, useful for debugging.</i>


title: <B>INSTALLATION</B>
content:
<i>The Firebase CLI is distributed as an npm package. To install it globally on your system, open your terminal or command prompt and use the following command:<br><b>npm install -g firebase-tools</b><br>Ensure you have Node.js and npm installed on your system before attempting the installation.</i>


title: HISTORY
content:
<i>Firebase, originally an independent company, was acquired by Google in 2014, leading to its integration into the Google Cloud ecosystem. The Firebase CLI was developed as a crucial tool to empower developers with a command-line interface for managing their Firebase projects efficiently. Its evolution has closely mirrored the growth of the Firebase platform itself, with continuous updates to support new services like Cloud Functions, Cloud Firestore, Firebase Extensions, and local emulators. The CLI has become an indispensable component in modern web and mobile development workflows, especially for those leveraging CI/CD pipelines for Firebase applications.</i>


title: SYNOPSIS
content:
fixcvsdiff [<i>options</i>]<br><br>Commonly used in a pipeline:<br><code>cvs diff -u [<i>cvs_options</i>] | fixcvsdiff</code>


title: PARAMETERS
content:
<b><i>(No specific functional parameters)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<code>fixcvsdiff</code> typically operates as a simple filter, reading from standard input and writing to standard output without requiring specific command-line options for its core functionality. It may support standard options like <code>--help</code> or <code>--version</code>.<br><br>


title: DESCRIPTION
content:
<i>fixcvsdiff</i> is a specialized utility designed to normalize and correct inconsistencies in the output generated by the <code>cvs diff -u</code> command (unified diff format). These inconsistencies, often related to timestamp precision, format variations, or minor structural quirks, can pose problems for automated tools attempting to parse or apply these diffs.<br><br>Primarily developed as an internal component of repository migration tools like <i>cvs2svn</i>, <i>fixcvsdiff</i> ensures that the CVS diff output adheres to a more predictable and standardized format. This sanitization is crucial for maintaining data integrity and ensuring successful processing when converting CVS repositories to other version control systems such as Git or Subversion. It typically operates as a filter, reading diff data from standard input and writing the corrected output to standard output.


title: CAVEATS
content:
<ul><li><code>fixcvsdiff</code> is not a general-purpose diff fixing tool; it is specifically tailored to address known quirks in <code>cvs diff -u</code> output, particularly related to timestamps and header formatting.</li><li>It is often bundled with or used as part of larger repository migration suites (e.g., <i>cvs2svn</i>), rather than being a standalone system utility.</li><li>Its relevance is diminishing as CVS usage declines in favor of more modern version control systems like Git.</li></ul>


title: TYPICAL USAGE SCENARIO
content:
<i>fixcvsdiff</i> is commonly employed within shell scripts or automated workflows where <code>cvs diff</code> output needs to be processed programmatically. For example, to generate a clean diff between two tags:<br><br><code>cvs diff -u -r <i>TAG1</i> -r <i>TAG2</i> <i>module_name</i> | fixcvsdiff > <i>clean_diff.patch</i></code><br><br>This ensures that the <code>clean_diff.patch</code> file is free from common CVS diff inconsistencies, making it easier to apply with tools like <code>patch(1)</code> or parse with custom scripts.


title: HISTORY
content:
<i>fixcvsdiff</i> emerged as a necessary component within projects focused on migrating CVS repositories to other version control systems, most notably <i>cvs2svn</i>. The motivation was to overcome parsing challenges posed by slight variations and inconsistencies in <code>cvs diff -u</code> output that could cause conversion failures or data integrity issues. It was developed to specifically preprocess these diffs, making them robust enough for automated parsing and application during the migration process. Its primary development and maintenance have been tied to these migration tools, evolving to handle specific CVS output nuances.


title: SYNOPSIS
content:
<b>flac</b> [<i>options</i>] [<i>input_file</i>...]<br><br>Common usage examples:<br><b>flac</b> [<i>options</i>] <b>-d</b> <i>input.flac</i> <b>-o</b> <i>output.wav</i><br><b>flac</b> [<i>options</i>] <b>-e</b> <i>input.wav</i> <b>-o</b> <i>output.flac</i><br><b>flac</b> [<i>options</i>] <b>-t</b> <i>input.flac</i>


title: PARAMETERS
content:
<b><b>-d</b>, <b>--decode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decode a FLAC file to an uncompressed audio file (default: WAV) or standard output.<br><br><b><b>-e</b>, <b>--encode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encode an uncompressed audio file (default: WAV) or standard input to FLAC.<br><br><b><b>-t</b>, <b>--test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test a FLAC file for errors by decoding it and checking its integrity. No output file is created.<br><br><b><b>-a</b>, <b>--analyze</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze a FLAC file and print various stream statistics to standard output.<br><br><b><b>-c</b>, <b>--stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the decoded or encoded audio to standard output (useful for piping to other commands).<br><br><b><b>-o</b> <i>FILE</i>, <b>--output</b>=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the output audio to the specified <i>FILE</i> instead of the default naming convention.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwriting of existing output files without prompting for confirmation.<br><br><b><b>-s</b>, <b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all console output except for essential messages or errors.<br><br><b><b>-0</b> to <b>-8</b>, <b>--compression-level</b>=<i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the compression level for encoding, where <b>0</b> is fastest (least compression) and <b>8</b> is best (most compression, slowest encoding).<br><br><b><b>--delete-input-file</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete the input file after successful encoding or decoding.<br><br><b><b>--ignore-existing-metadata</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When encoding, do not copy metadata blocks (e.g., WAV chunks) from the input file to the FLAC file.<br><br><b><b>--ogg</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encode or decode Ogg FLAC files instead of native FLAC streams. This embeds FLAC data within an Ogg container.<br><br>


title: DESCRIPTION
content:
<b>flac</b> is the command-line utility for the Free Lossless Audio Codec (FLAC).<br><br>It can <b>encode</b> uncompressed audio files (such as WAV, AIFF, or raw PCM) into the FLAC format, <b>decode</b> FLAC files back to uncompressed formats, <b>verify</b> the integrity of existing FLAC files, and <b>analyze</b> their properties. FLAC is an open, royalty-free audio compression format designed to reduce file size significantly without any loss of audio information, making it an excellent choice for archiving high-fidelity audio. It supports various bit depths and sample rates, offering flexibility for different audio sources. The <b>flac</b> command provides a comprehensive set of options for detailed control over the encoding process, stream verification, and basic metadata management.


title: CAVEATS
content:
While FLAC is a lossless format, converting FLAC files to other lossy formats (such as MP3 or Ogg Vorbis) will inevitably result in a permanent loss of audio quality.<br>Higher compression levels (e.g., <b>-8</b>) significantly increase the time and CPU resources required for encoding, although decoding speed is generally unaffected by the compression level.<br>When working with raw audio input (without a header), it is crucial to explicitly specify audio parameters like <b>--channels</b>, <b>--sample-rate</b>, and <b>--bps</b> to ensure correct interpretation and processing.


title: RAW AUDIO INPUT/OUTPUT
content:
For raw audio files lacking a header (e.g., raw PCM streams), <b>flac</b> requires explicit command-line options to correctly interpret the audio data. These essential options include <b>--channels</b> (number of channels), <b>--sample-rate</b> (sample rate in Hz), <b>--bps</b> (bits per sample), and optionally <b>--endian</b> (byte order).


title: METADATA HANDLING
content:
While <b>flac</b> can embed basic metadata during encoding and display some during analysis, for comprehensive editing and manipulation of FLAC metadata tags (e.g., Vorbis comments, cuesheets, pictures), the dedicated utility <b>metaflac(1)</b> is generally the preferred and more powerful tool.


title: HISTORY
content:
The FLAC (Free Lossless Audio Codec) project was initiated in 2000 by Josh Coalson, with its first stable version released in 2001. It quickly gained traction as an open-source, royalty-free alternative to proprietary lossless audio formats. The development of FLAC is now overseen by the Xiph.Org Foundation. The <b>flac</b> command-line utility serves as the official and reference encoder/decoder for the FLAC format, becoming a cornerstone in Linux and other open-source environments for lossless audio archiving and high-fidelity playback.


title: PARAMETERS
content:
<b><B>--app</B> <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Python path to the Flask application. This can be a module name (e.g., <I>my_app</I>), a factory function (e.g., <I>my_app:create_app</I>), or a file path (e.g., <I>app.py</I>). Overrides the <I>FLASK_APP</I> environment variable.<br><br><b><B>--env</B> <I>ENV</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the Flask environment. Common values are <I>development</I> or <I>production</I>. This influences debug mode and other configuration settings. Overrides the <I>FLASK_ENV</I> environment variable.<br><br><b><B>--debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug mode. This activates the interactive debugger and auto-reloader, useful for development. Implied when <I>FLASK_ENV</I> is set to <I>development</I>.<br><br><b><B>--no-debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable debug mode explicitly. Useful if <I>FLASK_ENV</I> is <I>development</I> but you want to disable debug for a specific run.<br><br><b><B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the Flask framework version and exit.<br><br><b><B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message for the <B>flask</B> command or a specific subcommand. For example, <B>flask</B> <B>run</B> <B>--help</B>.<br><br>


title: DESCRIPTION
content:
The <B>flask</B> command is the command-line interface (CLI) tool for the <I>Flask</I> web framework, a popular Python microframework used for building web applications. Unlike traditional Linux commands that are part of the operating system, <B>flask</B> is a Python executable that gets installed when you install the Flask framework via <I>pip</I>.<BR><BR>Its primary purpose is to assist developers in managing their Flask applications during development. Common uses include running a development server, opening an interactive shell for debugging, showing application routes, and managing database migrations or other application-specific tasks defined by the developer. The exact behavior of the <B>flask</B> command often depends on environment variables like <I>FLASK_APP</I> and <I>FLASK_ENV</I>, which tell the command how to locate and configure the Flask application.


title: CAVEATS
content:
The <B>flask</B> command is not a built-in Linux utility. It requires Python and the Flask framework to be installed, typically within a virtual environment. Its functionality heavily depends on the configuration of your Flask application, particularly the <I>FLASK_APP</I> environment variable or the <B>--app</B> option, which tells the command where to find your application instance. Without proper configuration, the command may fail to locate your application.


title: IMPORTANT ENVIRONMENT VARIABLES
content:
The behavior of the <B>flask</B> command is heavily influenced by environment variables, which define the context for your Flask application:<BR><BR><B>FLASK_APP</B>: Specifies the import path to your Flask application instance (e.g., <I>my_app.py</I> or <I>my_app:create_app()</I>). This is crucial for the <B>flask</B> command to locate and load your application.<BR><BR><B>FLASK_ENV</B>: Defines the environment in which the application is running, typically <I>development</I> or <I>production</I>. This affects configuration settings, error handling, and debug mode. Setting it to <I>development</I> automatically enables debug mode and the reloader.


title: COMMON SUBCOMMANDS
content:
While the <B>flask</B> command takes global options, its main power comes from its subcommands, each with its own set of options and arguments:<BR><BR><B>flask run</B>: Runs the development server. This is the most common subcommand, allowing you to view and interact with your application in a web browser.<BR><BR><B>flask shell</B>: Opens an interactive Python shell with your application context loaded, allowing you to access database models, configurations, and other application components directly.<BR><BR><B>flask routes</B>: Displays a table of all registered URL rules (routes) for your application, including their associated endpoints and methods.<BR><BR>Developers can also define custom subcommands for their specific application needs, making the <B>flask</B> CLI extensible.


title: HISTORY
content:
The Flask framework was created by Armin Ronacher and first released in 2010. Initially, running Flask applications often involved direct Python scripts. The dedicated <B>flask</B> command-line interface was introduced later to provide a more unified and user-friendly experience for common development tasks, standardizing the way developers interact with their Flask projects. It has evolved to include various subcommands for common operations like running the development server (<B>run</B>), entering an interactive shell (<B>shell</B>), and listing routes (<B>routes</B>).


title: SYNOPSIS
content:
<b>flatpak-builder</b> [OPTION...] DIRECTORY MANIFEST<br><b>flatpak-builder</b> [OPTION...] DIRECTORY --run COMMAND [ARG...]<br><b>flatpak-builder</b> --build-shell [OPTION...] DIRECTORY


title: PARAMETERS
content:
<b>--repo=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the path to the Flatpak repository where the build artifacts will be committed.</I><br><br><b>--force-clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Removes the build directory and associated state before starting the build, ensuring a clean slate.</I><br><br><b>--disable-cache</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prevents the use of cached build artifacts, forcing a full rebuild of all modules.</I><br><br><b>--install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Installs the built application into the local Flatpak system after a successful build.</I><br><br><b>--arch=ARCH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Overrides the architecture detected from the manifest, allowing cross-compilation.</I><br><br><b>--jobs=NUM</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sets the number of parallel build jobs (similar to <B>-j</B> in Make), speeding up compilation.</I><br><br><b>--run COMMAND [ARG...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Executes a specified command inside the isolated build environment.</I><br><br><b>--build-shell</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Opens an interactive shell within the build environment, useful for debugging build issues.</I><br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Increases the verbosity of the output, showing more details about the build process.</I><br><br><b>DIRECTORY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>The path to the build directory where Flatpak-builder will perform its operations and store build artifacts.</I><br><br><b>MANIFEST</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>The path to the Flatpak manifest file (YAML or JSON) that defines the application's build process.</I><br><br>


title: DESCRIPTION
content:
<b>flatpak-builder</b> is the primary command-line tool used to create and manage Flatpak application builds. It reads a manifest file, which defines the application's metadata, sources, build instructions, and dependencies. The tool creates an isolated build environment (using sandboxing) where the application's sources are fetched, compiled, and installed. It supports incremental builds, caching intermediate build artifacts, and creating Flatpak repositories or directly installing the built applications. <b>flatpak-builder</b> is essential for developers packaging their applications for Flatpak and for users who want to build applications from source for Flatpak. It ensures reproducible and consistent builds by controlling the build environment and dependencies.


title: CAVEATS
content:
Building complex applications requires careful crafting of the Flatpak manifest, which can be intricate.<br>Debugging build failures within the sandboxed environment can be challenging, often requiring the use of <b>--build-shell</b> or <b>--run</b>.<br>Builds can consume significant disk space due to intermediate artifacts and cached data, especially for large projects.<br>Network access for fetching sources is typically required during the build process, which might conflict with strict network policies if not explicitly managed.


title: <B>TYPICAL WORKFLOW</B>
content:
<I>The typical workflow for building a Flatpak application involves creating a <B>.json</B> or <B>.yaml</B> manifest file first, defining the application's modules, sources, and build commands. Then, <B>flatpak-builder</B> is invoked with the build directory (where build artifacts will be stored) and the path to the manifest file. After a successful build, the application can be installed locally using the <B>--install</B> option or committed to a local Flatpak repository using <B>--repo</B> for distribution.</I>


title: HISTORY
content:
Flatpak, initially known as xdg-app, was conceived by Lennart Poettering and others as a next-generation application distribution framework for Linux. It was first publicly released in 2016. <b>flatpak-builder</b> has been a core component from its inception, designed to automate and standardize the process of creating Flatpak applications from source code and manifests. It has evolved alongside the Flatpak project, incorporating features like incremental builds, improved manifest parsing, and better integration with modern development workflows to enhance efficiency and reproducibility.


title: PARAMETERS
content:
<b><b>-w</b> <i>WIDTH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set maximum line width to <i>WIDTH</i> columns. If not specified, the default width is 80 columns.<br><br><b><b>--width=</b><i>WIDTH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identical to <b>-w</b>; set maximum line width to <i>WIDTH</i> columns.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Count bytes rather than display columns. This can be faster but may split multi-byte characters incorrectly.<br><br><b><b>--bytes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identical to <b>-b</b>; count bytes rather than display columns.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Break lines at spaces if possible. This option attempts to avoid splitting words by breaking at the last space before the specified width.<br><br><b><b>--spaces</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identical to <b>-s</b>; break lines at spaces if possible.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
The <i>fold</i> command wraps each line of input to fit a specified maximum width. It reads from standard input or specified files and writes the formatted output to standard output. By default, if no width is explicitly provided, it wraps lines at 80 columns.<br><br><i>fold</i> is a straightforward and effective utility for reformatting text files, making them more readable by ensuring they fit within a terminal window or for preparing output that requires a fixed-width format. Unlike more complex text formatters such as <b>fmt</b>, <i>fold</i> operates on a line-by-line basis: it does not re-flow entire paragraphs, join short lines, or attempt to fill lines evenly. Instead, it simply breaks a line when its length exceeds the specified maximum width, inserting a newline character. This makes it ideal for simple line wrapping without altering paragraph structure.


title: CAVEATS
content:
The default width is 80 columns if no <b>-w</b> or <b>--width</b> option is provided.<br><br>When using <b>-b</b> (byte counting), <i>fold</i> does not consider multi-byte characters and might split them, leading to corrupted output for non-ASCII text. It's generally recommended to use the default column counting unless you explicitly need byte-based wrapping.<br><br><i>fold</i> simply wraps individual lines; it does not re-flow entire paragraphs like <b>fmt</b> does. Each input line is treated independently.<br><br>Lines longer than the specified width are always broken, even if <b>-s</b> is used and there are no spaces to break on within the limit.


title: CHARACTER VS. BYTE COUNTING
content:
By default, <i>fold</i> counts display columns. This means it correctly handles tab characters (expanding them to spaces) and multi-width characters (like some Asian characters) when determining line length. However, if <b>-b</b> is used, it counts raw bytes, which can be faster but may produce unexpected results with multi-byte encodings (e.g., UTF-8) by splitting characters in the middle.


title: DIFFERENCE FROM FMT
content:
While both <i>fold</i> and <i>fmt</i> deal with text formatting, their approaches differ significantly. <i>fold</i> is a simpler line wrapper; it treats each input line as a distinct unit and wraps it if it exceeds the specified width. <i>fmt</i>, on the other hand, is designed to re-flow paragraphs, joining short lines and breaking long ones to create a more uniformly filled block of text. For simple, line-by-line wrapping, <i>fold</i> is often the more direct choice.


title: HISTORY
content:
The <b>fold</b> command is a standard utility found in Unix-like operating systems. It is part of the GNU Core Utilities (coreutils), a collection of fundamental tools for manipulating files and text.<br><br>Its basic functionality has been consistent across various Unix implementations for decades, serving as a simple yet effective tool for line wrapping. Its design reflects the common need to fit text output into fixed-width terminals or printers in early computing environments.


title: PARAMETERS
content:
<b><I>file</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more PostScript or PDF files to be processed. If no files are specified, the command reads from standard input (stdin).<br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output, showing the internal commands being executed and their parameters. Useful for troubleshooting.<br><br><b><I>--nofeed</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the sending of a form-feed character at the end of the print job. Some printers may require this.<br><br><b><I>--raw</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends raw output directly to the printer without any additional processing or form feeds by the wrapper. Useful when the printer expects raw data.<br><br><b><I>--force-color</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces `foo2hiperc` to process the job in color mode, even if it might detect monochrome content or if the printer is usually monochrome. Useful for color adjustments.<br><br><b><I>--force-mono</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces `foo2hiperc` to process the job in monochrome (grayscale) mode, optimizing for black and white printing.<br><br><b><I>--paper</I> <I>size</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the paper size (e.g., A4, Letter, Legal). This option is usually passed through to Ghostscript or `foo2hiperc` to ensure correct page dimensions.<br><br><b><I>--duplex</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (two-sided) printing, if supported by the printer and `foo2hiperc`. This option is typically passed to Ghostscript.<br><br><b><I>--simplex</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces simplex (one-sided) printing.<br><br><b><I>--resolution</I> <I>dpi</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the printing resolution in dots per inch (e.g., 600, 1200). This value is passed to `foo2hiperc`.<br><br><b><I>--gamma</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the gamma correction for color output (passed to `foo2hiperc`).<br><br><b><I>--profile</I> <I>file.icc</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an ICC color profile file to be used for color management (passed to `foo2hiperc`).<br><br>


title: DESCRIPTION
content:
The `foo2hiperc-wrapper` command is a crucial component of the `foo2zjs` driver suite, designed to enable Linux and Unix-like systems to print to printers that use the Hi-Cap (High Capacity) printer language. These are often specific models from manufacturers like Samsung or Xerox, which require a specialized driver beyond standard PostScript or PCL.<br><br>Essentially, `foo2hiperc-wrapper` acts as an intermediary, facilitating the conversion of PostScript or PDF input (typically generated by applications or Ghostscript) into the proprietary Hi-Cap format. It usually works by piping the PostScript input through Ghostscript (`gs`) for rendering, and then passing the rendered output to the `foo2hiperc` utility, which performs the final conversion to the printer's native language.<br><br>This wrapper script simplifies the printing process by handling the complex command-line arguments and piping necessary to make `gs` and `foo2hiperc` work together seamlessly. It is frequently configured as a filter in the CUPS (Common Unix Printing System) environment, allowing users to print directly from their applications without needing to manually invoke the underlying conversion tools.


title: CAVEATS
content:
The `foo2hiperc-wrapper` command relies heavily on the presence and correct configuration of Ghostscript (`gs`) and the `foo2hiperc` utility. Ensure both are installed and accessible in the system's PATH.<br><br>Printer-specific features (like special trays or advanced finishing options) might not be fully exposed or controllable directly via generic `foo2hiperc-wrapper` options; specialized CUPS queues or PPD files might be needed to unlock such functionalities.<br><br>As a wrapper script, its options often directly map to or are passed to the underlying `foo2hiperc` command or Ghostscript. For advanced usage or troubleshooting, consulting the `foo2hiperc` man page or Ghostscript documentation is recommended.


title: CUPS INTEGRATION
content:
`foo2hiperc-wrapper` is most commonly used as a backend filter in the CUPS printing system. When a printer is configured to use a `foo2hiperc` PPD file, CUPS automatically pipes print jobs through this wrapper script, handling the conversion and sending the job to the printer.


title: DEPENDENCIES
content:
Requires Ghostscript (`gs`) for PostScript/PDF rendering and the `foo2hiperc` executable for the final page description language conversion. Perl is also typically required as the wrapper script itself is often written in Perl.


title: HISTORY
content:
The `foo2hiperc-wrapper` command is part of the broader `foo2zjs` project, an open-source suite of drivers for printers that use proprietary page description languages (PDLs) like ZjStream, Hi-Cap, and others, common in printers from Samsung, Xerox, and Dell. Developed by Rick Richardson, the project aims to fill the gap left by manufacturers who often do not provide official Linux drivers for these specific printer models.<br><br>The `foo2zjs` project, and consequently `foo2hiperc`, gained prominence in the early 2000s as a vital solution for Linux users facing compatibility issues with popular, affordable laser printers. The wrapper scripts like `foo2hiperc-wrapper` were created to simplify the command-line usage and integration into standard printing systems like CUPS, making these printers accessible to a wider Linux audience.


title: SYNOPSIS
content:
<b>foo2zjs</b> [<i>options</i>] [<i>input.ps</i>]<br>or<br><b>cat</b> <i>input.ps</i> | <b>foo2zjs</b> [<i>options</i>] > <i>/dev/lp0</i>


title: PARAMETERS
content:
<b><b>-r</b> <i><resolution></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the printing resolution, e.g., <i>-r1200x600</i>.<br><br><b><b>-d</b> <i><mode></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (two-sided) printing. <i>-d1</i> for short-edge binding, <i>-d2</i> for long-edge binding.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables color mode printing, if supported by the printer.<br><br><b><b>-p</b> <i><paper_size></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the paper size (e.g., <i>-pA4</i>, <i>-pLetter</i>).<br><br><b><b>-n</b> <i><copies></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the specified number of copies.<br><br><b><b>-L</b> <i><level></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the compression level for the raster data (0-3). Higher levels mean smaller file size but more CPU usage.<br><br><b><b>-C</b> <i><gamma></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a gamma correction value, useful for adjusting brightness/contrast.<br><br><b><b>-s</b> <i><source></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper source/tray (e.g., <i>-sTray1</i>, <i>-sManual</i>).<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables toner save mode, reducing toner consumption.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts the image (black becomes white, white becomes black).<br><br>


title: DESCRIPTION
content:
<i>foo2zjs</i> is an open-source, PostScript printer driver that converts PostScript files into the native ZjS (Zijiang Semiconductor) printer language. It is primarily used with Linux and other Unix-like operating systems to enable printing on a wide range of laser printers that utilize this specific page description language, particularly many Samsung, Konica Minolta, and Xerox printers. <br><br>As a filter program, <i>foo2zjs</i> typically receives PostScript data from a print spooler like CUPS (Common Unix Printing System) or directly from a pipeline. It then processes this data, generating the proprietary ZjS commands and raw raster data that the printer can understand. This driver is part of a larger suite of 'foo2' drivers, each designed for different proprietary printer languages, providing a vital open-source alternative to proprietary drivers often unavailable for Linux.


title: CAVEATS
content:
<i>foo2zjs</i> requires a PostScript input, which is usually generated by Ghostscript (<i>gs</i>) if the application doesn't output PostScript directly. The driver relies on specific printer firmware characteristics, and not all ZjS printers are fully supported, or may require specific firmware 'firmloader' files. Compatibility can vary, and optimal performance often depends on correct configuration within CUPS.


title: HISTORY
content:
The <i>foo2zjs</i> project, led by Rick Richardson, began development around the early 2000s, motivated by the lack of open-source drivers for a growing number of printers using proprietary page description languages. The 'foo2' suite (including <i>foo2qpdl</i>, <i>foo2xqx</i>, etc.) emerged as a crucial solution for Linux users facing limited vendor support. <i>foo2zjs</i> specifically targets printers using the ZjS language, becoming a de facto standard for many Samsung, Xerox, and Konica Minolta models. Its development has continued to adapt to new printer models and ensure ongoing compatibility for PostScript-capable systems.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version number and exit.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be verbose while updating.<br><br><b><b>-d</b>, <b>--daemon</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <i>freshclam</i> as a daemon. It will check for updates periodically.<br><br><b><b>-c N</b>, <b>--checks=N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;In daemon mode, check for N updates (default: 12). After N checks, daemon exits.<br><br><b><b>-l FILE</b>, <b>--log=FILE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Log to specified FILE.<br><br><b><b>-L</b>, <b>--syslog</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Log to syslog.<br><br><b><b>-u USER</b>, <b>--user=USER</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run as specified user. Required when started as root.<br><br><b><b>--config-file=FILE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read configuration from FILE (default: freshclam.conf).<br><br><b><b>--no-warnings</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print warnings.<br><br><b><b>--foreground</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in foreground when daemonizing (useful for systemd).<br><br><b><b>--datadir=DIR</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the database directory where definitions are stored.<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not output any messages except errors (overrides <b>-v</b>).<br><br>


title: DESCRIPTION
content:
<i>freshclam</i> is the command-line utility for updating the ClamAV virus signature database. It connects to the official ClamAV mirror network to download the latest virus definition files, including <b>main.cvd</b>, <b>daily.cvd</b>, and <b>bytecode.cvd</b>.<br><br>Keeping the virus database up-to-date is crucial for ClamAV's effectiveness in detecting new and emerging malware threats. <i>freshclam</i> can be run manually, scheduled via a cron job, or operated in a daemon mode for continuous monitoring and updating. It reads its configuration from <b>freshclam.conf</b>, allowing users to specify parameters like proxy settings, update frequencies, and database locations.


title: CAVEATS
content:
<i>freshclam</i> requires internet access to download updates. Firewall rules might need adjustment. It also needs write permissions to the database directory (typically <i>/var/lib/clamav</i> or <i>/usr/local/share/clamav</i>) to save the new definition files. Running it with insufficient permissions will cause updates to fail silently or with errors. Frequent updates can consume bandwidth, so consider your network capacity and scheduling when configuring daemon mode or cron jobs.


title: CONFIGURATION FILE
content:
The primary configuration for <i>freshclam</i> is handled via <b>freshclam.conf</b> (often located in <i>/etc/clamav/</i>). This file allows specifying critical settings like proxy server details, desired update frequency, location of the virus database directory, and preferred mirror servers. Users should consult this file to tailor <i>freshclam</i> behavior to their specific environment.


title: RUNNING AS A DAEMON
content:
When run with the <b>--daemon</b> option, <i>freshclam</i> operates in the background, periodically checking for and downloading updates. This is particularly useful for systems where ClamAV is actively used, such as email servers running <i>clamd</i>, ensuring that scanning always uses the latest definitions without manual intervention or separate scheduling.


title: PERMISSIONS
content:
It is critical that <i>freshclam</i> has appropriate write permissions to its database directory. Often, <i>freshclam</i> is configured to run as a dedicated, unprivileged user (e.g., <i>clamav</i> or <i>_clamav</i>) for security reasons. This user must own or have write access to the directory where the <b>.cvd</b> files are stored to successfully download and update the virus definitions.


title: HISTORY
content:
<i>freshclam</i> is an integral part of the ClamAV antivirus engine, which was originally developed by Tomasz Kojm in 2002. Since its inception, ClamAV has been a popular open-source solution for email gateway scanning and general-purpose malware detection. <i>freshclam</i> was designed from the beginning as the dedicated tool to ensure that the ClamAV scanning engine always operates with the most current threat intelligence, reflecting the rapidly evolving nature of malware. Its development has focused on robustness, efficient bandwidth usage, and flexible configuration to support a wide range of deployment scenarios.


title: SYNOPSIS
content:
<I>fsadm</I> [<B>-v</B>] [<B>-d</B>] [<B>-x</B>] [<B>-h</B>] [<B>-V</B>] {<B>check</B>|<B>resize</B>|<B>grow</B>|<B>shrink</B>} <I>filesystem_or_device</I> [<I>size[MGTPE]</I>]


title: PARAMETERS
content:
<b><B>-v</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the operations being performed.<br><br><b><B>-d</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, providing highly detailed information useful for troubleshooting.<br><br><b><B>-x</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the command that would be executed, but does not actually run it (dry run).<br><br><b><B>-h</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><B>-V</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><B>check</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the integrity of the specified filesystem for errors.<br><br><b><B>resize</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resizes the filesystem to the specified size. This command can grow or shrink the filesystem.<br><br><b><B>grow</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Grows the filesystem to the specified size, or to the maximum available space if no size is provided. This typically requires the underlying partition/LV to be already expanded.<br><br><b><B>shrink</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shrinks the filesystem to the specified size. This operation can be dangerous and should only be performed after careful consideration and backup. The underlying partition/LV must be shrunk afterwards.<br><br><b><I>filesystem_or_device</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the filesystem mount point (e.g., <I>/home</I>) or the device path (e.g., <I>/dev/sda1</I>, <I>/dev/mapper/vg0-lv0</I>).<br><br><b><I>size[MGTPE]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target size for resize operations. Can be specified in bytes or with a unit suffix: M (MiB), G (GiB), T (TiB), P (PiB), E (EiB).<br><br>


title: DESCRIPTION
content:
<I>fsadm</I> is a high-level utility designed to streamline common filesystem administration tasks, including checking integrity and resizing filesystems. It serves as a universal wrapper, abstracting the complexities of different filesystem types by automatically detecting the filesystem (e.g., ext4, XFS, Btrfs) and invoking the appropriate underlying low-level tool (such as <I>resize2fs</I>, <I>xfs_growfs</I>, or <I>btrfs filesystem resize</I>). This consistent interface simplifies operations for administrators, eliminating the need to memorize specific commands or syntax for each filesystem type.<br><br><I>fsadm</I> aims to provide a safer and more user-friendly experience when performing critical operations like growing a filesystem to utilize expanded underlying storage, or cautiously shrinking one to free up space. It is particularly useful in environments with diverse filesystem deployments or when scripting automated maintenance routines, enhancing efficiency and reducing potential errors associated with manual, type-specific command execution.


title: CAVEATS
content:
As a wrapper, <I>fsadm</I> relies on the specific underlying filesystem tools. Any limitations or risks associated with those tools (e.g., data loss during shrinking) apply.<br><br>Shrinking a filesystem is inherently risky and can lead to data loss if the specified size is smaller than the actual data stored. Always back up critical data before attempting to shrink a filesystem.<br><br>For resize operations, <I>fsadm</I> only modifies the filesystem itself. The underlying partition or Logical Volume (LV) must be resized separately using tools like <I>fdisk</I>, <I>parted</I>, or <I>lvresize</I>. When growing, extend the partition/LV <I>before</I> using <I>fsadm grow</I>. When shrinking, use <I>fsadm shrink</I> <I>before</I> shrinking the partition/LV.


title: WRAPPER FUNCTIONALITY
content:
<I>fsadm</I> intelligently detects the filesystem type of the target device or mount point. Based on this detection, it then executes the appropriate low-level, filesystem-specific utility. This design makes <I>fsadm</I> highly adaptable and avoids the need for it to implement complex filesystem-specific logic internally.


title: INTERACTION WITH LVM
content:
While <I>fsadm</I> can operate on Logical Volumes (LVs), it's crucial to understand that it only modifies the <I>filesystem</I> residing on the LV. To resize the LV itself, separate LVM commands like <I>lvresize</I> must be used. For growing a filesystem, the LV must be extended <I>before</I> using <I>fsadm grow</I>. For shrinking, <I>fsadm shrink</I> must be run <I>before</I> shrinking the LV with <I>lvresize</I>.


title: HISTORY
content:
<I>fsadm</I> is a component of the <I>util-linux</I> project, a comprehensive collection of fundamental system utilities for Linux. It was introduced to address the fragmentation of filesystem administration tools, providing a single, consistent command-line interface for tasks that previously required users to remember and use different utilities for each filesystem type (e.g., <I>resize2fs</I> for ext4, <I>xfs_growfs</I> for XFS). Its development aimed to simplify scripting and general system administration by offering a unified approach to common filesystem operations.


title: SEE ALSO
content:
<I>resize2fs(8)</I>, <I>xfs_growfs(8)</I>, <I>btrfs-filesystem(8)</I>, <I>fdisk(8)</I>, <I>parted(8)</I>, <I>lvm(8)</I>, <I>lvresize(8)</I>, <I>mkfs(8)</I>, <I>mount(8)</I>


title: SYNOPSIS
content:
There is no standard command synopsis for <I>fsck.nfs</I> as it is not a recognized utility in the Linux filesystem consistency check suite.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;As <I>fsck.nfs</I> is not a standard command, it does not have defined parameters.<br><br>


title: DESCRIPTION
content:
The command <I>fsck.nfs</I> is not a standard Linux utility used for checking or repairing the integrity of a Network File System (NFS) mount.<br><br>The <I>fsck</I> (file system consistency check) family of commands, such as <I>fsck.ext4</I> or <I>fsck.xfs</I>, are designed to operate on local block devices (like hard drives or SSDs) and their specific filesystem structures. They directly access and manipulate the underlying disk blocks to find and repair inconsistencies, often requiring the filesystem to be unmounted or mounted read-only.<br><br>NFS, on the other hand, is a network protocol that allows a client to access files on a remote server. The client doesn't have direct block-level access to the server's storage. Therefore, a client-side <I>fsck.nfs</I> cannot perform integrity checks or repairs on the remote filesystem. Any filesystem integrity checks for an NFS share must be performed on the <b>server</b> where the actual filesystem (e.g., ext4, xfs) resides, using the appropriate <I>fsck</I> utility for that local filesystem.<br><br>If you encounter references to <I>fsck.nfs</I>, it might be a custom script or a misunderstanding of how network filesystems are managed.


title: CAVEATS
content:
The primary caveat is that <I>fsck.nfs</I> does not exist as a standard tool for repairing NFS filesystems. Attempting to run it will likely result in a 'command not found' error. Users should understand that:<br><ul><li>NFS client machines do not perform filesystem consistency checks on NFS mounts.</li><li>Filesystem integrity is the responsibility of the <b>NFS server's local filesystem</b>, which should be checked using appropriate <I>fsck</I> tools for its underlying filesystem type (e.g., <I>fsck.ext4</I>).</li><li>Troubleshooting NFS issues typically involves checking network connectivity, server availability, NFS daemon status (<I>rpc.nfsd</I>, <I>rpc.mountd</I>), export configurations, and client-side mounting options.</li></ul>


title: NFS TROUBLESHOOTING VS. `FSCK`
content:
While <I>fsck.nfs</I> doesn't exist, issues with NFS mounts can manifest as if the filesystem is corrupted. However, the solutions are different:<br><ul><li><b>Network Issues:</b> Check connectivity with <I>ping</I> to the NFS server. Ensure NFS ports are open (2049, 111) using <I>netstat</I> or <I>nmap</I>.</li><li><b>Server Status:</b> Verify that NFS services (<I>nfs-server</I>, <I>nfs-kernel-server</I>, <I>rpcbind</I>) are running on the server. Use <I>showmount -e <server_ip></I> to confirm exports.</li><li><b>Client Mount:</b> Ensure the client has correct permissions and mounting options (<I>/etc/fstab</I>, <I>mount</I> command).</li><li><b>Server-Side Filesystem Check:</b> If you suspect data corruption, log into the NFS server and run the appropriate <I>fsck</I> command on the <b>local filesystem</b> that is being exported (e.g., <I>fsck.ext4 /dev/sda1</I>), typically requiring it to be unmounted or mounted read-only.</li><li><b>Logs:</b> Check system logs on both client and server (<I>/var/log/messages</I>, <I>/var/log/syslog</I>, <I>journalctl</I>) for NFS-related errors.</li></ul>


title: HISTORY
content:
The concept of <I>fsck</I> (file system consistency check) originated in early Unix systems to repair corrupted local filesystems. Over time, specific <I>fsck</I> implementations like <I>fsck.ext2</I>, <I>fsck.ext3</I>, <I>fsck.ext4</I>, and <I>fsck.xfs</I> evolved for different filesystem types. These tools are inherently designed for direct block-level access to storage devices.<br><br>NFS (Network File System) was developed by Sun Microsystems in the 1980s to allow client machines to access files over a network, treating them as if they were local. Given its network-centric, client-server architecture, the design never incorporated a client-side <I>fsck</I> for NFS. The integrity of the data stored on the NFS server is maintained by the server's local filesystem and its own <I>fsck</I> utilities. Thus, a direct <I>fsck.nfs</I> never became part of standard Linux or Unix distributions because it fundamentally contradicts how network filesystems operate.


title: PARAMETERS
content:
<b><B>--help</B>, <B>-h</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display a help message and exit.</I><br><br><b><B>--verbose</B>, <B>-v</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show more detailed debug information during execution.</I><br><br><b><B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Print the program's version information and exit.</I><br><br><b><B>--offline</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Perform operations using only locally cached data, without network access to LVFS.</I><br><br><b><B>--allow-reinstall</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Permit reinstalling the firmware version that is already present on the device.</I><br><br><b><B>--force</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Force the requested operation, overriding certain safety checks or user confirmations.</I><br><br><b><B>--no-confirm</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not prompt for user confirmation before executing potentially destructive operations.</I><br><br><b><B>--interactive</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Force interactive mode, prompting for user input even if a non-interactive mode is default.</I><br><br><b><B>--json</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Output results in a machine-readable JSON format, suitable for scripting.</I><br><br><b><B>--disable-metadata-validation</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Disable the validation of metadata signatures. Use with extreme caution as it compromises security.</I><br><br><b><B>--allow-downgrade</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Allow installing an older firmware version than currently installed.</I><br><br>


title: DESCRIPTION
content:
<i>fwupdtool</i> is a command-line utility designed for managing firmware updates on Linux systems. It interacts with the <i>fwupd</i> daemon, which connects to the Linux Vendor Firmware Service (LVFS) to securely download, verify, and install firmware updates for a wide range of hardware components.<br><br>Users can leverage <i>fwupdtool</i> to list supported devices, check for available updates, apply new firmware versions, and manage firmware revisions. It supports both online updates via LVFS and offline installations using pre-downloaded firmware archives. The tool aims to provide a reliable and secure method for keeping device firmware up-to-date, enhancing system stability, security, and performance across various hardware vendors and Linux distributions.


title: CAVEATS
content:
Most <i>fwupdtool</i> operations require root privileges.<br>Firmware updates carry inherent risks; ensure stable power supply during updates.<br>Many updates require a system reboot to apply changes.<br>The tool relies on the <i>fwupd</i> daemon being active and functional.


title: COMMON USAGE EXAMPLES
content:
<B>Check for and apply updates:</B><br><i>fwupdtool refresh && fwupdtool update</i><br><br><B>List all devices known to fwupd:</B><br><i>fwupdtool get-devices</i><br><br><B>Download updates for offline installation:</B><br><i>fwupdtool download --no-confirm</i>


title: LVFS INTEGRATION
content:
<i>fwupdtool</i>'s primary source for firmware updates is the <B>Linux Vendor Firmware Service (LVFS)</B>. LVFS acts as a secure, centralized repository where hardware vendors can upload signed firmware. This integration ensures the authenticity, integrity, and timely availability of firmware updates for a wide range of Linux-compatible hardware, enhancing security and compatibility.


title: HISTORY
content:
<i>fwupdtool</i> is an integral part of the <B>fwupd</B> project, which was initiated to address the lack of a standardized and reliable firmware update mechanism on Linux. Developed primarily by Richard Hughes (Red Hat), it emerged from the Linux Vendor Firmware Service (LVFS) initiative. Its development aimed to simplify and secure firmware updates by providing a consistent interface for hardware vendors to distribute updates and for users to install them, significantly improving the Linux hardware ecosystem.


title: SYNOPSIS
content:
<b><code>fzf</code></b> [<i>options</i>]<br>
<b><code>command</code></b> | <b><code>fzf</code></b> [<i>options</i>]<br>
<b><code>fzf</code></b> [<i>options</i>] <b><code>&lt;</code></b> <i>input_file</i>


title: PARAMETERS
content:
<b>--query=<str></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initial query string.<br><br><b>--filter=<str></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter mode. Do not start interactive finder. Output matching lines to stdout and exit.<br><br><b>--multi</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable multi-select mode. Press <b><code>TAB</code></b> or <b><code>Shift-TAB</code></b> to mark/unmark. <b><code>Enter</code></b> confirms selections.<br><br><b>--no-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not sort the result. Useful when preserving the original order is desired.<br><br><b>--reverse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display lines in reverse order (bottom-up).<br><br><b>--preview=<command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute `command` for the currently highlighted item and display its output in the preview window. Use `{}` as a placeholder for the item.<br><br><b>--preview-window=<location>:<size>[:<options>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Customize the preview window layout. E.g., `right:50%`.<br><br><b>--height=<percent>%</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display `fzf` as a partial-height window, rather than fullscreen.<br><br><b>--layout=reverse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the search prompt at the bottom of the screen.<br><br><b>--prompt=<str></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Input prompt string. (Default: `> `).<br><br><b>--print0</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print selected item(s) separated by null characters. Useful for piping to `xargs -0`.<br><br><b>--ansi</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable processing of ANSI color codes in the input.<br><br><b>--expect=<key[,key,...]></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of keys to exit `fzf` and print the name of the key pressed.<br><br><b>--bind=<key>:<action>[,<key>:<action>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bind a key or key combination to an action. E.g., `ctrl-a:select-all`.<br><br><b>--history=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load and save history from the specified file.<br><br><b>--select-1</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically select the only match if there is exactly one.<br><br><b>--exit-0</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with 0 if no match found, and nothing is selected.<br><br>


title: DESCRIPTION
content:
`fzf` is a general-purpose command-line fuzzy finder written in Go. It provides an interactive interface to efficiently filter and select items from any list, typically presented via standard input. Its strength lies in its speed, flexibility, and intuitive fuzzy-matching algorithm, which allows users to quickly narrow down choices even with partial or imprecise input. `fzf` is highly customizable and designed to be integrated seamlessly with other command-line tools and shell environments. Common use cases include finding files, searching command history, filtering process lists, and navigating directories. It processes lines from standard input and outputs the selected line(s) to standard output, making it an excellent component in powerful shell pipelines.


title: CAVEATS
content:
`fzf` relies on external commands for its preview functionality, which must be installed separately. While highly optimized, performance can still be a factor with extremely large input sets (millions of lines). Integrating `fzf` with complex shell functions or aliases often requires careful attention to quoting and shell expansion rules.


title: SHELL INTEGRATION
content:
`fzf` provides excellent shell integration, significantly enhancing common shell tasks. For instance, `CTRL-T` (for Bash/Zsh) often invokes `fzf` to select files from the current directory and its subdirectories, `ALT-C` allows for quick directory switching, and `CTRL-R` provides an interactive, fuzzy search through your shell history. These integrations leverage `fzf`'s core filtering capabilities to provide a much more efficient and intuitive user experience.


title: PIPING AND CHAINING
content:
`fzf` is designed to work as a filter in shell pipelines. You can pipe the output of any command into `fzf` to interactively select items, and then pipe `fzf`'s output to another command. This makes it incredibly versatile for creating custom workflows, such as `ls -l | fzf --multi | xargs rm` to interactively select and delete files.


title: HISTORY
content:
`fzf` was created by Junegunn Choi and first released around 2014-2015. Developed in Go, it quickly gained popularity for its exceptional speed and portability across various operating systems. Its simple yet powerful fuzzy-matching algorithm, combined with a highly customizable interface, made it a favorite among command-line users for interactive filtering tasks. The project has seen continuous development and has become a de facto standard tool for enhancing shell productivity, particularly through its widely adopted shell key bindings (e.g., `CTRL-T`, `ALT-C`, `CTRL-R`).


title: PARAMETERS
content:
<b>-w <i>&lt;width&gt;</i>, -h <i>&lt;height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the target resolution for the application's rendering within Gamescope.<br><br><b>-W <i>&lt;window-width&gt;</i>, -H <i>&lt;window-height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the resolution of the Gamescope window itself when not running fullscreen.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs Gamescope in fullscreen mode, utilizing the entire display.<br><br><b>-F <i>&lt;framerate&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a fixed output framerate for Gamescope. Use 'max' for uncapped framerates.<br><br><b>-s <i>&lt;scale-factor&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a fractional scaling factor to the rendered content (e.g., '0.5' for 2x upscaling).<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables integer scaling, useful for pixel-perfect presentation of retro games or pixel art.<br><br><b>--fsr-sharpness <i>&lt;0-10&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the sharpness level for FSR-like upscaling, where 0 is soft and 10 is sharp.<br><br><b>--max-fps <i>&lt;fps&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Caps the maximum frames per second that the launched application can render.<br><br><b>--rt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to run Gamescope processes with real-time scheduling priority for reduced latency.<br><br><b>--output <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the display output (e.g., DP-1, HDMI-A-1) Gamescope should use.<br><br><b>--allow-tearing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows tearing when VRR is active, which can further reduce latency at the cost of visual artifacts.<br><br><b>--steam</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables specific integration features and optimizations for the Steam client and games.<br><br>


title: DESCRIPTION
content:
Gamescope is a Wayland compositor developed by Valve, primarily designed for running games and graphical applications with optimal performance and features. It acts as a nested compositor, launching applications within its own Wayland or Xwayland environment. Gamescope offers advanced features like fixed framerate capping, variable refresh rate (VRR) support, low-latency presentation, and various scaling algorithms including AMD FSR-like upscaling and integer scaling.<br><br>Originally developed for the Steam Deck and SteamOS 3, it aims to provide a consistent and high-performance gaming experience by managing display output directly. It can run on a direct rendering manager (DRM) backend, bypassing a full desktop environment, or within an existing Wayland session. Its focus on efficiency and control over the display pipeline makes it ideal for dedicated gaming systems, offering benefits like tear-free rendering and precise framerate control, even on displays without native VRR support through its VRR emulation capabilities.


title: CAVEATS
content:
Gamescope is primarily designed for running single applications, not as a full desktop environment replacement. It requires either a direct rendering manager (DRM) backend (commonly used on console-like systems such as the Steam Deck) or an existing Wayland compositor to function. While it supports Xwayland for X11 applications, some complex X11 features or global hotkeys might behave unexpectedly. Advanced features like HDR or specific VRR modes may depend on underlying driver support and display capabilities. Troubleshooting can sometimes involve checking Wayland logs or DRM configuration.


title: KEY FEATURES
content:
Gamescope stands out with several advanced capabilities:<br><b>VRR Emulation:</b> It can emulate Variable Refresh Rate behavior even on displays that do not natively support VRR, by dynamically adjusting the output refresh rate to match the game's framerate.<br><b>Low Latency:</b> Designed with a streamlined rendering path to minimize input lag and provide a responsive gaming experience.<br><b>Xwayland Integration:</b> Seamlessly runs traditional X11 applications by providing its own embedded Xwayland server, ensuring wide compatibility.<br><b>Direct DRM Backend:</b> Capable of running directly on the Direct Rendering Manager (DRM) without a full desktop environment, offering maximum control over the display pipeline.


title: HISTORY
content:
Gamescope was developed by Valve Corporation, primarily as a core component for their Steam Deck handheld gaming PC and the SteamOS 3 operating system. Its inception was driven by the need for a highly optimized, low-latency, and feature-rich display compositor specifically tailored for gaming workloads on Linux.<br><br>It leverages modern Linux graphics technologies, including Wayland and direct DRM access, to ensure efficient resource utilization and a direct path to the display hardware. Since its public release and integration into SteamOS, it has gained traction among Linux gamers and developers for its performance benefits and unique scaling capabilities, becoming a crucial part of the Proton compatibility layer's display pipeline.


title: SEE ALSO
content:
<b>wayland(7)</b>, <b>xorg(7)</b>, <b>mesa(7)</b>, <b>sway(1)</b>, <b>gnome-shell(1)</b>, <b>kwin_wayland(1)</b>, <b>steam(1)</b>


title: SYNOPSIS
content:
<b>gatsby &lt;command&gt; [options] [arguments]</b><br><br>Examples:<br><b>gatsby new my-gatsby-site</b><br><b>gatsby develop</b><br><b>gatsby build --prefix-paths</b>


title: PARAMETERS
content:
<b>new &lt;site-name&gt; [starter-url]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new Gatsby project with a specified name and an optional starter template.<br><br><b>develop [--host &lt;host&gt;] [--port &lt;port&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a local development server for your Gatsby site, enabling live reloading and GraphQL Playground.<br><br><b>build [--prefix-paths] [--no-uglify] [--json]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles your Gatsby site into production-ready static HTML, CSS, and JavaScript files.<br><br><b>serve [--host &lt;host&gt;] [--port &lt;port&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Serves the production build of your Gatsby site from the 'public' directory.<br><br><b>clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the '.cache' and 'public' directories, useful for troubleshooting build issues.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays relevant information about your Gatsby environment, including Node.js, npm, and Gatsby CLI versions.<br><br><b>plugin &lt;add|remove|docs&gt; [plugin-name]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Gatsby plugins, allowing you to add, remove, or open documentation for a plugin.<br><br>


title: DESCRIPTION
content:
The <b>gatsby</b> command-line interface (CLI) is the primary tool for interacting with the Gatsby.js framework, a powerful and popular open-source framework for building fast, modern websites and web applications. <br><br>While not a native Linux command in the traditional sense, <b>gatsby</b> is a Node.js package that must be installed globally (e.g., via <i>npm install -g gatsby-cli</i> or <i>yarn global add gatsby-cli</i>). It allows developers to create, develop, build, and serve Gatsby projects directly from their terminal.<br><br>Gatsby leverages React for UI development, GraphQL for data querying, and Webpack for asset bundling, delivering highly optimized, performant, and secure static sites or Progressive Web Apps (PWAs). The <b>gatsby</b> CLI streamlines the development workflow by providing commands for common tasks like project initialization, starting a local development server with hot module reloading, creating production builds, and clearing build caches. Its focus on performance and developer experience makes it a staple for modern web development leveraging the JAMstack architecture.


title: CAVEATS
content:
The <b>gatsby</b> command is a Node.js-based CLI tool and requires Node.js (typically v14.15.0 or higher) and a package manager like npm or Yarn to be installed on your system. It is not a native Linux utility or part of the GNU coreutils. Running <b>gatsby</b> without proper installation will result in a 'command not found' error.


title: DATA LAYER AND PLUGINS
content:
Gatsby uses GraphQL as a data layer, allowing developers to pull data from various sources (local files, CMS, APIs) into their React components. The extensive plugin ecosystem further enhances functionality, providing integrations for images, markdown, third-party services, and more, all accessible and configurable via the <b>gatsby</b> CLI.


title: HISTORY
content:
Gatsby was created by Kyle Mathews and first released in 2015. It gained significant traction for its innovative approach to static site generation, combining the power of React for dynamic UIs with the performance benefits of pre-rendered static assets. Its development has been driven by a strong focus on web performance, developer experience, and the adoption of modern web standards like GraphQL and Progressive Web Apps (PWAs). The <b>gatsby</b> CLI has evolved alongside the framework, adding new commands and options to support an ever-growing ecosystem of plugins and features.


title: SYNOPSIS
content:
<b>gcloud sql export sql</b> <i>INSTANCE_NAME</i> <i>GS_URI</i> [<b>--database</b>=<i>DATABASE</i>[,...]] [<b>--table</b>=<i>TABLE</i>[,...]] [<b>--offload</b>] [<b>--async</b>] [<b>--file-per-table</b>] [<b>--uri-file-per-table-prefix</b>=<i>PREFIX</i>] [<i>GCLOUD_WIDE_FLAG</i>...]


title: PARAMETERS
content:
<b><i>INSTANCE_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The ID of the Cloud SQL instance from which to export data. This is a positional argument.<br><br><b><i>GS_URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Google Cloud Storage URI where the SQL export file will be written. For example, <i>gs://my-bucket/my-dump.sql</i>. This is a positional argument.<br><br><b><b>--database</b>=<i>DATABASE</i>[,...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of database names to export. If not specified, all databases on the instance are exported, except for system databases.<br><br><b><b>--table</b>=<i>TABLE</i>[,...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of table names to export. This flag requires the <b>--database</b> flag to be specified, and tables must belong to one of the specified databases.<br><br><b><b>--offload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Offload the export operation to reduce performance impact on the primary instance. Recommended for large exports.<br><br><b><b>--async</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Return immediately, without waiting for the operation to complete.<br><br><b><b>--file-per-table</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports each table to a separate SQL file. Requires <b>--table</b> to be specified. Each file will be named <i>TABLE_NAME</i>.sql. The <i>GS_URI</i> must be a folder.<br><br><b><b>--uri-file-per-table-prefix</b>=<i>PREFIX</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--file-per-table</b> to specify a URI prefix for each exported file. The format is <i>gs://BUCKET/PATH/PREFIX_TABLE_NAME.sql</i>.<br><br>


title: DESCRIPTION
content:
The <b>gcloud sql export sql</b> command facilitates the export of a Cloud SQL instance's database content into a SQL dump file stored in a Google Cloud Storage bucket. This operation is crucial for various tasks, including creating backups for disaster recovery, migrating data between instances or to other environments, performing offline analysis, or sharing specific database subsets.<br>The command supports exporting entire databases, specific tables within a database, or even multiple databases from a single instance. The output is a standard SQL text file containing <b>CREATE TABLE</b> and <b>INSERT</b> statements, making it highly portable. Users must ensure that the Cloud SQL instance has network connectivity to the specified Cloud Storage bucket and that the service account associated with the instance has sufficient permissions to write to the bucket. The export process runs asynchronously, allowing you to monitor its progress or retrieve the operation's status.


title: CAVEATS
content:
Export operations require specific Identity and Access Management (IAM) permissions for the service account associated with the Cloud SQL instance to write to the designated Cloud Storage bucket.<br>Large exports can consume significant instance resources and may impact performance unless the <b>--offload</b> flag is used.<br>Exports do not include Cloud SQL users, stored procedures, triggers, or event schedulers; only the schema and data of the tables are exported.<br>The target Cloud Storage bucket must be in the same region as the Cloud SQL instance or a multi-region location that includes the instance's region.<br>Exported files incur Cloud Storage costs.<br>Character set and collation issues might arise if not properly handled during import.


title: PERMISSIONS REQUIRED
content:
The Cloud SQL instance's service account (e.g., <i>project-id@cloudservices.gserviceaccount.com</i>) must have the <b>Storage Object Creator</b> or <b>Storage Object Admin</b> IAM role on the target Cloud Storage bucket. Without these permissions, the export operation will fail.


title: MONITORING EXPORT OPERATIONS
content:
After initiating an export, the operation ID is returned if run asynchronously (with <b>--async</b>). You can monitor its progress using <b>gcloud sql operations describe OPERATION_ID</b> or view operations via the Google Cloud Console. For synchronous exports, the command waits until completion or failure.


title: OUTPUT FORMAT
content:
The exported file is a plain text SQL dump, typically containing <b>CREATE TABLE</b> statements for schema definition and <b>INSERT INTO</b> statements for data. It can be directly imported into another compatible SQL database or used for analysis.


title: HISTORY
content:
The <b>gcloud</b> command-line tool, including <b>gcloud sql export sql</b>, is part of the Google Cloud SDK. It has evolved significantly since its initial release, providing a unified interface for managing Google Cloud resources. The <b>sql</b> component specifically targets Cloud SQL database management, with export capabilities being a core feature from early versions, continuously improved for performance and flexibility (e.g., introduction of offload exports, file-per-table). Its development aligns with the ongoing enhancements and new features of the Cloud SQL service itself.


title: SEE ALSO
content:
gcloud sql import sql(1), gcloud sql export csv(1), gcloud sql backups create(1), gcloud sql operations describe(1), gsutil cp(1)


title: SYNOPSIS
content:
<b>gconftool-2</b> [<i>OPTIONS</i>] [<i>COMMAND</i>] [<i>KEY</i>]<br><br>Example common usage:<br><b>gconftool-2 --get</b> <i>/apps/gnome-terminal/profiles/Default/font</i><br><b>gconftool-2 --set</b> <i>/apps/gnome-terminal/profiles/Default/use_theme_colors</i> <b>--type=bool</b> <i>true</i><br><b>gconftool-2 --unset</b> <i>/desktop/gnome/background/picture_filename</i><br><b>gconftool-2 --list-keys</b> <i>/desktop/gnome/interface</i><br><b>gconftool-2 --monitor</b> <i>/apps/gnome-terminal</i>


title: PARAMETERS
content:
<b><b>--get</b> <I>KEY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves and prints the value of a specified GConf key.<br><br><b><b>--set</b> <I>KEY</I> <I>VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the value of a GConf key. Requires <b>--type</b> for non-string values.<br><br><b><b>--unset</b> <I>KEY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a GConf key and its value.<br><br><b><b>--type=</b><I>TYPE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the data type (e.g., string, int, bool, list, schema) for <b>--set</b> operations.<br><br><b><b>--list-dirs</b> [<I>DIR</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists subdirectories within a given GConf directory or the root ('/') if no directory is specified.<br><br><b><b>--list-keys</b> [<I>DIR</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists keys within a given GConf directory or the root ('/') if no directory is specified.<br><br><b><b>--recursive-list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all keys and directories recursively from the root of the GConf system.<br><br><b><b>--monitor</b> <I>KEY</I>|<I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitors changes to a specific key or all keys within a directory in real-time.<br><br><b><b>--schema-install</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a GConf schema definition XML file, making new key definitions available.<br><br><b><b>--load</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads configuration data from an XML file into the GConf database.<br><br><b><b>--dump</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps all configuration data from the GConf database to an XML file.<br><br><b><b>--shutdown</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shuts down the GConf daemon (gconfd-2) and synchronizes settings.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the gconftool-2 version information.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message detailing available commands and options.<br><br>


title: DESCRIPTION
content:
<I>gconftool-2</I> is a command-line utility used to manage the GConf configuration system, which served as GNOME's primary configuration database. It enabled applications to store, retrieve, and monitor configuration values, often backed by XML files and a configuration daemon (<I>gconfd-2</I>). <I>gconftool-2</I> provided the interface for users and scripts to directly manipulate these settings, including reading (<b>--get</b>), writing (<b>--set</b>), unsetting (<b>--unset</b>), listing (<b>--list-dirs</b>, <b>--list-keys</b>), and monitoring (<b>--monitor</b>) keys. It was essential for configuring GNOME desktop environments and applications that relied on GConf prior to its deprecation in favor of DConf and GSettings.


title: CAVEATS
content:
<I>gconftool-2</I> interacts with the GConf configuration system, which has been largely superseded by DConf and GSettings in modern GNOME desktop environments (GNOME 3.2 and later). While still present in some older systems or specific configurations, its active development and primary usage have declined. Users of recent GNOME versions should typically use <I>gsettings</I> or <I>dconf</I> for configuration management instead. Directly manipulating GConf keys can sometimes lead to unexpected behavior if not done carefully, especially without understanding the associated schemas.


title: GCONF DAEMON (<I>GCONFD-2</I>)
content:
GConf relies on a background daemon, <I>gconfd-2</I>, which handles all configuration changes, notifications, and interactions with underlying storage (typically XML files). <I>gconftool-2</I> communicates with this daemon to perform its operations, ensuring real-time updates and consistency across applications.


title: CONFIGURATION SOURCES
content:
GConf employs a layered system of configuration sources. These sources define the order in which settings are read and applied, often including system-wide defaults, administrator overrides, and individual user preferences. When <I>gconftool-2</I> retrieves a key's value, it consults this hierarchy to determine the effective setting.


title: SCHEMAS
content:
GConf keys are often associated with schemas, which are XML files providing metadata about the keys. Schemas define the data type, default values, human-readable documentation, and sometimes constraints or allowed ranges for a key. <I>gconftool-2</I> can be used to install new schemas or query existing ones for information about specific keys.


title: HISTORY
content:
<I>gconftool-2</I> was developed as part of the GNOME project to manage the GConf configuration system. GConf became the standard for storing application and desktop settings in GNOME 2.x and earlier GNOME 3.x releases, aiming to be a simpler, more robust alternative to other configuration systems. With the shift towards a more efficient and modern configuration backend, GConf was eventually deprecated in favor of DConf and GSettings (introduced around GNOME 3.2). Consequently, <I>gconftool-2</I> has been largely replaced by <I>gsettings</I> for end-user configuration management in contemporary GNOME environments, though it might still be found in legacy systems or specific non-upgraded installations.


title: SYNOPSIS
content:
<b>gcrane copy</b> <i>&lt;src&gt;</i> <i>&lt;dst&gt;</i> [<i>flags</i>]<br><i>src</i>: Source image or blob reference (e.g., <i>gcr.io/my-project/my-image:tag</i>)<br><i>dst</i>: Destination image or blob reference (e.g., <i>us-docker.pkg.dev/my-project/my-repo/my-image:newtag</i>)


title: PARAMETERS
content:
<b><b>--allow-nondistributable-artifacts</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow copying of non-distributable artifacts, such as certain Windows base layers, which may not be universally supported by all registries.<br><br><b><b>--allow-missing-blobs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not fail the copy operation if a referenced blob is missing from the source registry, allowing for partial copies in some scenarios.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When copying an image, copy all tags associated with the manifest list. When copying a repository, copy all tags from the source to the destination.<br><br><b><b>--recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When operating in repository mode (with <b>--repo</b>), recursively copy all images and their associated tags within the source repository to the destination repository.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run of the copy operation, showing what would be copied without making any actual changes to the registries.<br><br><b><b>--platform</b> <i>&lt;platform&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a target platform (e.g., <i>linux/amd64</i>) to copy only the image for that specific platform from a multi-architecture manifest list.<br><br><b><b>--repo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable repository mode, allowing you to copy all images and their tags from a source repository to a destination repository. Typically used with <b>--all</b> or <b>--recursive</b>.<br><br><b><b>--tags</b> <i>&lt;tag1,tag2,...&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of specific tags to copy when operating in repository mode (requires <b>--repo</b>). Only images with these tags will be copied.<br><br>


title: DESCRIPTION
content:
<i>gcrane-copy</i> is a powerful subcommand of the <i>gcrane</i> utility, specifically designed for efficient copying of container images and arbitrary OCI blobs between compatible registries, or within the same registry. It is highly optimized for Google Cloud's Container Registry (GCR) and Artifact Registry, providing robust authentication and authorization integration. Unlike traditional <i>docker push/pull</i> operations that often require local caching of images, <i>gcrane-copy</i> can perform server-side copies when supported by the registries involved. This capability significantly accelerates transfers and reduces local resource usage, particularly for large images. It serves as an invaluable tool for migrating images between projects, mirroring repositories for disaster recovery, or replicating artifacts across different environments without unnecessary intermediate downloads to your local machine. It supports various authentication methods and gracefully handles multi-architecture images.


title: CAVEATS
content:
<i>gcrane-copy</i> relies on <i>gcrane</i> being installed and properly configured, including authentication with the registries involved. While it prioritizes server-side copies for efficiency, this capability is dependent on the registries' support; cross-registry copies between different vendors often fallback to client-side streaming, which can consume significant local network bandwidth and time for very large images. Ensure you have appropriate read/write permissions for both source and destination registries.


title: AUTHENTICATION
content:
<i>gcrane-copy</i> typically inherits authentication from your existing <i>gcloud CLI</i> configuration when interacting with Google Cloud registries. For other OCI-compatible registries, it can utilize standard Docker credential helpers, or you can provide credentials explicitly through flags like <b>--username</b> and <b>--password</b>.


title: SERVER-SIDE VS. CLIENT-SIDE COPY
content:
A key advantage of <i>gcrane-copy</i> is its intelligent attempt to perform a server-side copy whenever possible. In this mode, image data is transferred directly between registries without being pulled down to your local machine, dramatically speeding up transfers and reducing local resource consumption. If server-side copy is not supported (e.g., for copies between registries from different vendors), it gracefully falls back to a client-side streamed copy, where the data flows through the <i>gcrane</i> client on your local machine.


title: HISTORY
content:
<i>gcrane</i> is a specialized tool developed by Google, leveraging the robust <i>go-containerregistry</i> library (which also powers the more general-purpose <i>crane</i> CLI tool). Its development was driven by the need for more efficient, reliable, and deeply integrated image management within Google Container Registry and Artifact Registry. It offers an alternative to the standard <i>docker</i> CLI, providing enhanced performance for certain operations and seamless integration with Google Cloud's authentication mechanisms, quickly gaining popularity for its speed and server-side copying capabilities.


title: SYNOPSIS
content:
<i>gdalinfo</i> [OPTIONS] &lt;datasetname&gt;<br><br><i>gdalinfo</i> displays detailed metadata and structural information about a GDAL-supported raster &lt;datasetname&gt;. Various <i>OPTIONS</i> can be used to control the output format and content.


title: PARAMETERS
content:
<b>-json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output all information in structured JSON format.<br><br><b>-mdd &lt;domain&gt;|<all></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report metadata for a specific <i>domain</i> or for <i>all</i> domains.<br><br><b>-sd &lt;subdataset&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a specific <i>subdataset</i> to report information about.<br><br><b>-oo &lt;NAME=VALUE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a dataset open option, e.g., <i>-oo NUM_THREADS=ALL_CPUS</i>.<br><br><b>-proj4</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report the coordinate system in PROJ.4 format.<br><br><b>-wkt_format &lt;WKT1|WKT2_2015|WKT2_2018&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control the WKT format version for the projection output.<br><br><b>-stats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force computation and reporting of band statistics (min, max, mean, std dev).<br><br><b>-hist</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force computation and reporting of band histograms.<br><br><b>-nogcp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress reporting of Ground Control Points (GCPs).<br><br><b>-nomd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress reporting of metadata.<br><br><b>-norat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress reporting of the Raster Attribute Table (RAT).<br><br><b>-noct</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress reporting of the Color Table.<br><br><b>-nocpxb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress complex band information (e.g., Fourier transform coefficients).<br><br><b>-checksum</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compute and report the checksum for each band.<br><br><b>-overview</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report information about dataset overviews.<br><br><b>-listmdd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available metadata domains for the dataset.<br><br><b>-listmd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List available metadata items for the dataset (GDAL 3.9+).<br><br><b>-if &lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restrict the drivers used to open the dataset to a specific <i>format</i>.<br><br><b>-show_md_domain &lt;domain&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show metadata for a specific <i>domain</i> (GDAL 3.9+).<br><br><b>-config &lt;key&gt; &lt;value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a GDAL configuration option, e.g., <i>-config GDAL_CACHEMAX 512</i>.<br><br><b>-setmd &lt;key=value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a metadata item for the dataset.<br><br><b>-unsetmd &lt;key&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unset a metadata item for the dataset.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the GDAL version and exit.<br><br><b>--formats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all supported GDAL raster formats and exit.<br><br><b>--help-general</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display generic GDAL command-line options.<br><br>


title: DESCRIPTION
content:
<i>gdalinfo</i> is a fundamental command-line utility within the GDAL (Geospatial Data Abstraction Library) suite. Its primary purpose is to display comprehensive information about georeferenced raster datasets. It can read a vast array of raster formats, including GeoTIFF, NetCDF, HDF5, JPEG2000, and many others supported by GDAL drivers. The output typically includes crucial details such as the dataset's driver and file name, image dimensions (width and height), coordinate system (expressed in WKT or PROJ.4 format), georeferencing transformation (geotransform or Ground Control Points - GCPs), metadata domains, and information about each raster band. For each band, <i>gdalinfo</i> can report its data type, color interpretation, statistics (min, max, mean, standard deviation), histogram, and no-data value. This command is invaluable for quickly inspecting geospatial data without requiring a full GIS application, aiding in data validation, debugging data issues, and providing essential parameters for scripting automated geospatial workflows. It allows users to quickly understand the characteristics of their raster files, which is critical for subsequent processing steps like reprojection, mosaicking, or analysis.


title: CAVEATS
content:
Computing statistics or histograms (using <code>-stats</code> or <code>-hist</code> options) can be computationally intensive and time-consuming for very large datasets, as it requires reading the entire raster. The default text output can be highly verbose; for scripting and machine parsing, the <code>-json</code> option is highly recommended to obtain structured, machine-readable output. <i>gdalinfo</i> is part of the GDAL suite and requires the GDAL libraries to be installed and accessible on the system.


title: UNDERSTANDING GDAL'S DATA MODEL
content:
<i>gdalinfo</i>'s output directly reflects GDAL's internal data model. A GDAL dataset typically consists of:<br><b>Georeferencing:</b> Defined by either a geotransform (affine transformation from pixel coordinates to georeferenced coordinates) or Ground Control Points (GCPs).<br><b>Coordinate System:</b> Specifies the spatial reference system (e.g., WGS84, UTM Zone).<br><b>Raster Bands:</b> One or more bands, each with a specific data type (e.g., Byte, Int16, Float32), color interpretation (e.g., Red, Green, Blue, Gray), and potentially statistics and histograms.<br><b>Metadata:</b> Key-value pairs providing additional information, often organized into domains (e.g., 'IMAGERY_DOMAIN', 'RPC').<br><b>Overviews:</b> Lower-resolution versions of the dataset for faster rendering at zoomed-out scales.


title: TYPICAL USE CASES
content:
<i>gdalinfo</i> is an indispensable tool for:<br>Verifying the spatial reference system (projection) and geographic extent of a raster file.<br>Inspecting the number of bands, their data types, and color interpretations.<br>Checking for the presence of existing metadata, overviews, or no-data values.<br>Debugging issues with geospatial data, such as incorrect georeferencing or missing projections.<br>Automating data validation and parameter extraction within scripts for large-scale geospatial processing pipelines.


title: HISTORY
content:
<i>gdalinfo</i> is a foundational utility within the GDAL (Geospatial Data Abstraction Library) project, which was initiated by Frank Warmerdam in 1998. GDAL rapidly evolved into the de-facto open-source standard for reading and writing a vast array of geospatial raster data formats, and later expanded to include vector support (OGR). <i>gdalinfo</i> has been a core component of GDAL from its very beginning, providing essential insights into the structure and metadata of raster datasets. Over its development history, new capabilities such as the <code>-json</code> output option (introduced in GDAL 2.2), improved WKT format handling, and expanded metadata domain support have been added, enhancing its utility for both interactive use and automated scripting in modern geospatial workflows.


title: PARAMETERS
content:
<b><i>gemfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input GEM Paint <i>.img</i> file. If omitted, <b>gemtopbm</b> reads the image data from standard input.<br><br>


title: DESCRIPTION
content:
<i>gemtopbm</i> is a utility from the Netpbm tools suite. It is designed to convert image files in the GEM Paint <i>.img</i> format into the Netpbm monochrome Portable Bitmap (PBM) format. The GEM Paint format was commonly used on systems like the Atari ST and early IBM PCs running the GEM (Graphical Environment Manager) desktop.<br><br><i>gemtopbm</i> reads the GEM <i>.img</i> file, processes its pixel data, and outputs a corresponding PBM image to standard output. PBM is a very simple, raw bitmap format representing black and white pixels. This command is particularly useful for working with legacy image data from GEM-based applications or for archiving and converting old graphics files into a more universally accessible format within the Netpbm ecosystem. As GEM <i>.img</i> files are inherently monochrome, <i>gemtopbm</i> ensures a direct translation to PBM.


title: CAVEATS
content:
<b>gemtopbm</b> specifically handles the monochrome GEM Paint <i>.img</i> file format. It may not correctly process other GEM image formats or colored GEM files. The output is always a PBM (Portable Bitmap), which is monochrome, meaning any color information in a non-monochrome GEM file (if passed to it, though typically GEM Paint <i>.img</i> files are monochrome) would be lost or misinterpreted. This command is primarily for legacy file conversion.


title: STANDARD INPUT/OUTPUT
content:
<b>gemtopbm</b> reads its input GEM image from the file specified on the command line or from standard input if no file is given. The converted PBM image is always written to standard output. This allows for piping its output to other Netpbm utilities or redirecting it to a file. For example: <b>gemtopbm</b> <i>input.img</i> &gt; <i>output.pbm</i> or <b>cat</b> <i>input.img</i> | <b>gemtopbm</b> &gt; <i>output.pbm</i>.


title: FILE FORMAT
content:
The GEM Paint <i>.img</i> format is a monochrome bitmap format used by the GEM Paint application. <b>gemtopbm</b> expects this specific structure. The output PBM format is a simple, plain text or raw binary representation of a monochrome image, where each pixel is either black or white.


title: HISTORY
content:
<b>gemtopbm</b> is a component of the Netpbm project, a comprehensive suite of graphics file format conversion tools. The Netpbm package evolved from programs initially developed by Jef Poskanzer in the late 1980s and early 1990s. As GEM was a significant graphical environment during that era, tools like <b>gemtopbm</b> were created to facilitate the conversion and interoperability of image data from such platforms into more standardized formats like PBM, PGM, and PPM, which form the core of the Netpbm suite. Its inclusion reflects the need to support legacy graphics formats popular in the early PC and Atari ST computing environments.


title: SYNOPSIS
content:
<b>genie</b> [ACTION] [OPTIONS]<br><b>genie</b> <b>-s</b> | <b>--status</b><br><b>genie</b> <b>-e</b> | <b>--enter</b><br><b>genie</b> <b>-u</b> | <b>--shutdown</b><br><b>genie</b> [<b>-h</b> | <b>--help</b>] [<b>-v</b> | <b>--version</b>]<br><b>genie</b> [--init-timeout <i>&lt;seconds&gt;</i>] [--shell-timeout <i>&lt;seconds&gt;</i>] [--chroot] [--start-unit <i>&lt;unit&gt;</i>]


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message outlining <b>genie</b>'s usage and options.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current version information of the <b>genie</b> utility.<br><br><b><b>-s</b>, <b>--status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks and displays the current operational status of the <i>systemd</i> environment managed by <b>genie</b>.<br><br><b><b>-e</b>, <b>--enter</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enters the <i>systemd</i>-enabled environment. This is the default action if no other action is specified.<br><br><b><b>-u</b>, <b>--shutdown</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a graceful shutdown of the <i>systemd</i> environment and associated processes.<br><br><b><b>--init-timeout</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum time (in seconds) to wait for <i>systemd</i> to fully initialize.<br><br><b><b>--shell-timeout</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout (in seconds) for the shell to start up when entering the <b>genie</b> environment.<br><br><b><b>--chroot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a <i>chroot</i>-like mechanism when entering the <i>systemd</i> environment. This is an advanced option for specific use cases.<br><br><b><b>--start-unit</b> <i>&lt;unit&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;After entering the <i>systemd</i> environment, attempts to start the specified <i>systemd</i> unit (e.g., <i>docker.service</i>).<br><br>


title: DESCRIPTION
content:
The <b>genie</b> command is a specialized utility designed for the Windows Subsystem for Linux 2 (WSL2) environment. Its primary purpose is to enable the full functionality of <i>systemd</i> within WSL2 distributions, which by default do not run <i>systemd</i> as their <i>init</i> process.<br><br>Many Linux applications and services, such as <i>snapd</i>, <i>Docker</i>, and various background daemons, rely on <i>systemd</i> for proper initialization and management. <b>genie</b> acts as an <i>init</i> wrapper, creating a nested, isolated environment where <i>systemd</i> is properly initialized as PID 1. This allows users to run and manage <i>systemd</i>-dependent applications and services within their WSL2 instances, bridging a significant gap in WSL2's native capabilities. It provides commands to enter this <i>systemd</i> environment, check its status, and gracefully shut it down, thereby offering a more complete and functional Linux experience.


title: CAVEATS
content:
The <b>genie</b> command is specifically designed for and primarily functions within the Windows Subsystem for Linux 2 (WSL2) environment. It is not a standard, general-purpose Linux command found on bare-metal installations or typical virtual machines. Its operation relies on specific WSL2 characteristics and the presence of <i>systemd</i> within the WSL distribution.<br><br>While highly effective, <b>genie</b> provides a community-driven solution and is not officially supported by Microsoft for integrating <i>systemd</i> into WSL. Users should be aware that updates to WSL or <i>systemd</i> itself might occasionally require adjustments or lead to temporary incompatibilities. Performance overhead is generally minimal but can exist due to the nested environment.


title: HOW IT WORKS
content:
<b>genie</b> operates by launching a minimal <i>init</i> process that, in turn, starts <i>systemd</i> as the true PID 1 within a dedicated <i>cgroup</i> namespace. When a user executes <b>genie -e</b> (or similar), it creates a pseudo-login session that effectively <i>chroot</i>s or namespaces the user's shell into this <i>systemd</i>-controlled environment. This allows commands executed by the user to interact directly with the <i>systemd</i> instance, enabling the management and execution of <i>systemd</i>-dependent services.


title: INSTALLATION & USAGE
content:
<b>genie</b> is typically not pre-installed on Linux distributions. Users usually install it by downloading pre-built binaries from the official GitHub releases page (<i>arkane-systems/genie</i>) or by compiling it from source. Once installed, it's often added to the user's <b>$PATH</b> for easy execution. Basic usage involves running <b>genie -e</b> to enter the environment, <b>genie -s</b> to check status, and <b>genie -u</b> to shut down the <i>systemd</i> instance within WSL2.


title: HISTORY
content:
The <b>genie</b> project was developed by arkane-systems (Tarun Kumar) in response to a key limitation of the initial Windows Subsystem for Linux 2 (WSL2) architecture: its lack of native <i>systemd</i> support. By default, WSL2 distributions did not run <i>systemd</i> as PID 1, which prevented many common Linux applications and services (such as <i>snapd</i>, <i>Docker</i> daemon, and others that rely on <i>systemd</i> for process management and dependencies) from functioning correctly or easily.<br><br><b>genie</b> quickly emerged as a prominent community-driven solution, offering a robust method to spin up a <i>systemd</i>-managed environment within WSL2. Its development was motivated by the desire to provide WSL2 users with a more complete and traditional Linux experience, allowing them to leverage <i>systemd</i>-dependent software without resorting to full virtual machines or complex workarounds. Its continued usage highlights its effectiveness in bridging this gap.


title: SYNOPSIS
content:
<I>Not a standard Linux command. No direct synopsis.</I><br>To find Node.js installation location, common Linux commands include: <B>which node</B>, <B>whereis node</B>, <B>npm root -g</B>, <B>node -e "console.log(process.execPath)"</B>.


title: PARAMETERS
content:
<b><I>Not applicable</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>As this is not a standard Linux command, it does not have predefined parameters or options.</I><br><br>


title: DESCRIPTION
content:
The string "get-nodeinstalllocation" <I>is not a recognized or standard command</I> in typical Linux distributions. It is likely a placeholder for a script, an alias, a function within a specific framework (like PowerShell Core running on Linux), or a custom utility. In a standard Linux environment, you would typically use other commands or methods to determine the installation location of Node.js. These methods often involve checking common installation paths, using package manager queries, or leveraging Node.js's own utilities to report its environment.


title: CAVEATS
content:
The primary caveat is that <B>get-nodeinstalllocation</B> <I>is not a universally available Linux command</I>. Users attempting to execute it directly on a standard Linux system will likely encounter a "command not found" error. Its existence would depend entirely on a specific system setup, a custom script, or the installation of a particular framework (e.g., PowerShell) that defines such a function or cmdlet.


title: COMMON METHODS TO FIND NODE.JS LOCATION ON LINUX
content:
<I>Several standard Linux commands and Node.js-specific commands can be used to determine the Node.js installation location:</I><br><br><B>which node</B>: Typically shows the path to the <I>node</I> executable if it's in your shell's <I>PATH</I>. For example, <I>/usr/bin/node</I> or <I>/usr/local/bin/node</I>.<br><B>whereis node</B>: Locates the binary, source, and manual page files for Node.js.<br><B>npm root -g</B>: Shows the global <I>node_modules</I> directory where globally installed npm packages reside. The Node.js executable itself is usually in the directory above this, or in a sibling <I>bin</I> directory.<br><B>node -e "console.log(process.execPath)"</B>: Executes a small JavaScript snippet that outputs the full path to the Node.js executable currently running the command.<br><B>echo $PATH</B>: Inspect your system's <I>PATH</I> environment variable to see directories where executables are searched.


title: POSSIBLE ORIGIN
content:
While not a Linux command, the naming convention "get-something" is very common in <I>PowerShell cmdlets</I>. If PowerShell Core is installed on Linux, it's conceivable that such a cmdlet or a custom function with this name could be defined to query Node.js paths, possibly relying on environment variables or common installation patterns.


title: HISTORY
content:
As <B>get-nodeinstalllocation</B> is not a standard Linux command, there is <I>no historical development or usage history</I> within the context of typical Linux utilities. If it exists, its history would be tied to the specific project, script, or framework that introduced it, rather than the Linux operating system itself. It conceptually relates to finding installed software paths, a common task addressed by various system utilities and programming language-specific tools.


title: DESCRIPTION
content:
<b><code>getenforce</code></b> is a command-line utility used on Linux systems with SELinux (Security-Enhanced Linux) enabled. Its primary function is to display the current enforcement mode of SELinux.<br><br>SELinux operates in one of three modes:<br><ul><li><b><i>Enforcing</i></b>: SELinux security policy is active and enforced. All denials are logged, and actions are prevented according to the policy.</li><li><b><i>Permissive</i></b>: SELinux security policy is active, but only warnings/denials are logged. Actions that would be denied in enforcing mode are permitted, making it useful for testing or debugging policies.</li><li><b><i>Disabled</i></b>: SELinux is completely turned off. No policy is loaded, and no security checks are performed by SELinux.</li></ul>The command outputs one of these three strings, indicating the current state of SELinux enforcement on the system. It's a quick way for administrators and users to ascertain the immediate security posture concerning SELinux.


title: CAVEATS
content:
The <b><code>getenforce</code></b> command only displays the <i>current</i> SELinux enforcement mode. It does not provide information about why SELinux is in that mode, nor does it allow for changing the mode. To change the mode, one would typically use <b><code>setenforce</code></b> for a runtime change or modify <i>/etc/selinux/config</i> for a persistent change requiring a reboot.<br><br>If SELinux is not installed or enabled on the system, <b><code>getenforce</code></b> might not be available or might report an error.


title: RETURN VALUES
content:
The command exits with a status code of 0 upon successful execution. It typically outputs the current enforcement mode (<i>Enforcing</i>, <i>Permissive</i>, or <i>Disabled</i>) to standard output.


title: USAGE EXAMPLE
content:
To check the current SELinux enforcement status:<br><b><code>$ getenforce</code></b><br><i>Enforcing</i><br><br>This example shows that SELinux is currently operating in 'Enforcing' mode.


title: HISTORY
content:
SELinux was originally developed by the United States National Security Agency (NSA) to provide a mechanism for mandatory access control (MAC) on Linux systems. It was released to the open-source community in 2000 and integrated into the Linux kernel mainline in 2003. <b><code>getenforce</code></b>, along with <b><code>setenforce</code></b>, became part of the <i>selinux-utils</i> or <i>policycoreutils</i> packages, providing simple command-line interfaces to query and modify the basic SELinux enforcement state. Its design is intentionally minimalistic to provide a quick, unambiguous status check.


title: PARAMETERS
content:
<b>file...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files or directories from which to retrieve extended attributes.<br><br><b>-h, --no-dereference</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not dereference symbolic links. If <i>file</i> is a symbolic link, report its attributes rather than the attributes of the file it refers to.<br><br><b>-L, --dereference</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dereference symbolic links. If <i>file</i> is a symbolic link, report the attributes of the file it refers to. This is the default behavior.<br><br><b>-P, --no-dereference-xattr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;This option is synonymous with <i>-h</i>. Do not dereference symbolic links when listing attributes.<br><br><b>-R, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively list attributes of files in directories. When combined with <i>-L</i>, it recurses into linked directories; with <i>-P</i> or <i>-h</i>, it does not.<br><br><b>-n name, --name=name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the value of the named extended attribute. If the attribute name does not exist, an error is reported.<br><br><b>-v value-format, --restore={text|hex|base64}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for attribute values. <br> <i>text</i> (default) tries to interpret as text. <br> <i>hex</i> outputs values in hexadecimal. <br> <i>base64</i> outputs values in base64 encoding.<br><br><b>-m pattern, --match=pattern</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the values of all extended attributes whose names match the given regular expression <i>pattern</i>.<br><br><b>--absolute-names</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not strip leading slashes from file names in the output. Useful when recursively listing attributes from the root directory.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
The <i>getfattr</i> command is used to display extended attributes associated with files, directories, or symbolic links. Extended attributes are name:value pairs that store arbitrary metadata about a file or directory, independent of its regular data. They are fundamental for features like Access Control Lists (ACLs), SELinux security contexts, and user-defined metadata. <br><br> <i>getfattr</i> allows users to specify which attributes to retrieve (e.g., a specific name or a pattern) and how their values should be displayed (text, hex, or base64). When invoked without specific attribute names, it typically lists all extended attributes accessible to the user for the given file(s). It works in conjunction with <i>setfattr</i>, which is used to set or remove these attributes.


title: CAVEATS
content:
<b>Permissions:</b> Access to extended attributes is governed by standard file permissions. For instance, 'user.' attributes are typically readable by the file owner, while 'security.', 'system.', and 'trusted.' attributes often require root privileges or specific capabilities.<br><br><b>Filesystem Support:</b> Extended attributes are not universally supported by all filesystems. Common Linux filesystems like ext2/3/4, XFS, and Btrfs support them. Filesystems like FAT/NTFS usually do not support extended attributes natively under Linux, unless mounted with specific options that emulate or store them in a different manner.<br><br><b>Kernel Configuration:</b> The kernel must be compiled with extended attribute support (CONFIG_XATTR) and potentially specific filesystem XATTR support (e.g., CONFIG_EXT2_FS_XATTR for ext2/3/4).


title: OUTPUT FORMAT
content:
The output of <i>getfattr</i> typically starts with the file path, followed by a list of extended attributes for that file. Each attribute is displayed as a 'name="value"' pair.<br>Example:<br> <pre># file: /path/to/file<br>user.comment="This is a test comment"<br>security.selinux="unconfined_u:object_r:user_home_t:s0"</pre><br>When using <i>-v hex</i> or <i>-v base64</i>, the value will be encoded accordingly.


title: ATTRIBUTE NAMESPACES
content:
Extended attributes are organized into several namespaces, which dictate their behavior and access permissions:<br><b>user.</b>: User-defined attributes. Generally accessible by the file owner.<br><b>security.</b>: Used by security modules like SELinux or AppArmor to store security contexts.<br><b>system.</b>: Used by the kernel for system-level attributes, such as POSIX ACLs.<br><b>trusted.</b>: Only accessible by processes with CAP_SYS_ADMIN capability (typically root).


title: HISTORY
content:
The <i>getfattr</i> command is part of the <i>attr</i> package, a set of utilities designed to manage filesystem extended attributes on Linux. The concept of extended attributes has been present in Linux kernels for a significant period, providing a flexible mechanism to attach arbitrary metadata to files and directories. This functionality became crucial for implementing features like Access Control Lists (ACLs) and security contexts for Mandatory Access Control (MAC) systems like SELinux. The <i>attr</i> package, including <i>getfattr</i> and <i>setfattr</i>, has been maintained and developed to provide a standard user-space interface for manipulating these attributes.


title: SYNOPSIS
content:
<b>gh browse</b> [<I>path</I>] [<I>flags</I>]<br><b>gh browse</b> [<I>repository</I>] [<b>--commit</b> | <b>--diff</b> | <b>--files</b> | <b>--find</b> | <b>--issue</b> | <b>--pull</b> | <b>--wiki</b>] [<I>flags</I>]<br><b>gh browse</b> <I>url</I>


title: PARAMETERS
content:
<b><b>--branch</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific branch to open in the browser.<br><br><b><b>--commit</b> <I>hash</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified commit in the browser.<br><br><b><b>--diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the diff view for the current branch in the browser.<br><br><b><b>--files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the 'Files changed' tab for the current pull request in the browser.<br><br><b><b>--find</b> <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Navigates to a specific file or directory within the repository in the browser.<br><br><b><b>--issue</b> [<I>number</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the issue list or a specific issue by number in the browser.<br><br><b><b>--no-browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the generated URL to standard output instead of opening it in the browser.<br><br><b><b>--pull</b> [<I>number</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the pull request list or a specific pull request by number in the browser.<br><br><b><b>--repo</b> <I>[HOST/]OWNER/REPO</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a repository other than the current one to browse.<br><br><b><b>--wiki</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the repository's wiki page in the browser.<br><br>


title: DESCRIPTION
content:
<b>gh browse</b> is a subcommand of the GitHub CLI (<b>gh</b>) that provides a convenient way to open various GitHub resources directly in your default web browser. It eliminates the need for manual navigation to GitHub URLs by allowing users to quickly access the current repository, a specific repository, an issue, a pull request, a commit, or a wiki page from the command line. This command significantly streamlines the developer workflow, offering immediate access to web-based views of project components like code, discussions, and project boards. It's an essential tool for developers who frequently interact with GitHub from their terminal.


title: CAVEATS
content:
This command requires the GitHub CLI (<b>gh</b>) to be installed and properly authenticated with your GitHub account. It relies on your system's default web browser or the browser specified by the <b>BROWSER</b> environment variable. For implicit repository detection, the command must be executed within a Git repository that is linked to a GitHub remote, or the <b>--repo</b> flag must be explicitly used.


title: USAGE EXAMPLES
content:
<i>Open the current repository's main page:</i><br><b>gh browse</b><br><br><i>Open issue number 123 in the current repository:</i><br><b>gh browse --issue 123</b><br><br><i>Open pull request 456 in the 'cli/cli' repository:</i><br><b>gh browse cli/cli --pull 456</b><br><br><i>Print the URL of the current repository without opening it:</i><br><b>gh browse --no-browser</b><br><br><i>Open the 'main.go' file in the current repository on GitHub:</i><br><b>gh browse main.go</b><br><br><i>Open a specific GitHub URL:</i><br><b>gh browse github.com/cli/cli/issues/1</b>


title: ENVIRONMENT VARIABLES
content:
<b>BROWSER</b>: Specifies the browser command to use instead of the system's default browser for opening URLs.


title: HISTORY
content:
<b>gh-browse</b> is a fundamental component of the GitHub CLI (<b>gh</b>) project, which was developed by GitHub to provide a robust and native command-line interface for interacting with its platform. The <b>gh</b> CLI, including the <b>browse</b> subcommand, gained significant adoption after its general availability release in 2020. The inclusion of <b>gh browse</b> from early development stages underscores the critical need for quick web access to GitHub resources, reflecting its utility in modern development workflows. Its ongoing development is part of the broader evolution of the <b>gh</b> CLI, continuously improving user experience and adding new functionalities.


title: PARAMETERS
content:
<b><b>create</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new codespace for a repository.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all your active codespaces.<br><br><b><b>delete</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes one or more codespaces.<br><br><b><b>ssh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a codespace via SSH.<br><br><b><b>cp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies files between your local machine and a codespace.<br><br><b><b>forward</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forwards a local port to a codespace port.<br><br><b><b>logs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Accesses and displays codespace logs.<br><br><b><b>ports</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists forwarded ports in a codespace.<br><br><b><b>rebuild</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebuilds a codespace, applying new configurations.<br><br><b><b>stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops a running codespace.<br><br>


title: DESCRIPTION
content:
The <b>gh codespace</b> command, often referred to as <b>gh-cs</b> (due to the built-in <b>cs</b> alias for <b>codespace</b>), is a core component of the <I>GitHub CLI</I> (Command Line Interface) designed for managing GitHub Codespaces.<br><br>Codespaces provide configurable, cloud-hosted development environments that can be accessed directly from your web browser or through popular IDEs like VS Code. This command streamlines the workflow for developers by enabling terminal-based interaction with these environments.<br><br>Users can perform a wide range of actions, including creating new codespaces, listing existing ones, connecting to them via SSH, copying files, forwarding network ports, and managing their lifecycle (e.g., stopping or deleting). It's an essential tool for those leveraging cloud-based development, offering a seamless and efficient way to set up and tear down isolated development environments without impacting local machine configurations.


title: CAVEATS
content:
The use of <b>gh-cs</b> implies the <b>gh codespace</b> command, which requires the <I>GitHub CLI</I> to be installed and properly authenticated with your GitHub account. Active internet connectivity is necessary for all operations. Be mindful of billing implications associated with Codespaces usage, as they consume resources and may incur costs based on usage and configuration.


title: ALIAS INFORMATION
content:
While the full command is <b>gh codespace</b>, <I>GitHub CLI</I> provides a convenient alias, <b>cs</b>, allowing users to execute subcommands more concisely (e.g., <b>gh cs create</b>). The usage of <b>gh-cs</b> often implies this alias in scripting or custom configurations.


title: ENVIRONMENT VARIABLES
content:
Several environment variables can influence the behavior of <b>gh codespace</b> commands, such as <I>GH_HOST</I> (to specify a GitHub Enterprise instance) or <I>GH_CODESPACES_REGION</I> (to prefer a specific region for codespace creation). These can be used to customize interactions and target specific environments.


title: HISTORY
content:
GitHub Codespaces was first introduced as a limited beta feature in 2020 and became generally available in 2021, signifying GitHub's strategic move into cloud-native development environments. The integration of <b>gh codespace</b> into the GitHub CLI was crucial for providing developers with a robust command-line interface to manage these cloud resources, aligning with the growing trend of infrastructure-as-code and remote development workflows.


title: SYNOPSIS
content:
<B>gh env</B> [<I>VARIABLE</I>]<br><B>gh env</B> <I>VARIABLE</I>=<I>VALUE</I><br><B>gh env</B> <I>--unset</I> <I>VARIABLE</I>


title: PARAMETERS
content:
<b><I>VARIABLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used without a value, displays the current value of the specified GitHub CLI environment variable. If no <I>VARIABLE</I> is provided, lists all known GitHub CLI environment variables and their values.<br><br><b><I>VARIABLE</I>=<I>VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the specified GitHub CLI environment variable to the given <I>VALUE</I>. This change is typically persistent across sessions.<br><br><b><B>--unset</B> <I>VARIABLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes (unsets) the specified GitHub CLI environment variable from the configuration. This change is also typically persistent.<br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <I>gh env</I> command.<br><br>


title: DESCRIPTION
content:
The <I>gh env</I> command, also known as <I>gh environment</I>, is a powerful utility within the GitHub CLI tool used to inspect, set, and unset environment variables that influence <I>gh</I>'s behavior.<br><br>Unlike typical shell environment variables set with <I>export</I>, changes made via <I>gh env</I> are generally persistent, stored within <I>gh</I>'s configuration files (e.g., <I>~/.config/gh/config.yml</I> or <I>~/.config/gh/hosts.yml</I>). This ensures that settings like authentication tokens (<I>GH_TOKEN</I>), the GitHub host (<I>GH_HOST</I>), or preferred pager (<I>GH_PAGER</I>) are maintained across shell sessions.<br><br>It provides a centralized and persistent way to configure the GitHub CLI, making it easier to manage credentials, preferred behaviors, and connectivity settings.


title: CAVEATS
content:
Changes made by <I>gh env</I> are written to <I>gh</I>'s configuration files and are generally persistent, not just for the current shell session. Be cautious when setting sensitive information like <I>GH_TOKEN</I> as it will be stored in plain text (though protected by file permissions). This command manages only <I>gh</I>-specific environment variables and not general shell environment variables.


title: PERSISTENCE
content:
Unlike traditional shell <I>export</I> commands, which only affect the current shell session, <I>gh env</I> writes its changes to <I>gh</I>'s configuration files (e.g., <I>~/.config/gh/config.yml</I> or <I>~/.config/gh/hosts.yml</I>). This means settings applied via <I>gh env</I> will persist across new shell sessions and system reboots, ensuring consistent <I>gh</I> behavior.


title: COMMON ENVIRONMENT VARIABLES
content:
Some frequently used GitHub CLI environment variables that can be managed with <I>gh env</I> include:<br><ul><li><I>GH_TOKEN</I>: The GitHub authentication token.</li><li><I>GH_HOST</I>: The GitHub host to interact with (e.g., <I>github.com</I> or an enterprise instance).</li><li><I>GH_PAGER</I>: Specifies the pager program for long output.</li><li><I>GH_EDITOR</I>: Specifies the editor program for interactive prompts.</li><li><I>GH_DEBUG</I>: Enables debug logging.</li></ul>


title: HISTORY
content:
<I>gh env</I> (or <I>gh environment</I>) was introduced in GitHub CLI version <B>2.0.0</B>, released in <B>2021</B>. Its addition aimed to provide a standardized, persistent, and centralized way to manage <I>gh</I>-specific environment variables, moving away from relying solely on shell-level <I>export</I> commands for critical <I>gh</I> configurations.


title: SYNOPSIS
content:
`<b>gh-help</b>` [<i>command</i>]<br><i>Alternative usage:</i> `<b>gh help</b>` [<i>command</i>]<br><i>Also:</i> `<b>gh</b>` <i>command</i> `<b>--help</b>`


title: PARAMETERS
content:
<b><i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The optional name of a specific `<b>gh</b>` command or subcommand for which to display detailed help information. If omitted, `<b>gh-help</b>` provides general help for the `<b>gh</b>` CLI.<br><br>


title: DESCRIPTION
content:
`<b>gh-help</b>` provides comprehensive documentation for the GitHub CLI (`<b>gh</b>`) commands and their associated flags. While often conceptualized as a standalone command, it is typically invoked via `<b>gh help</b>` or by appending `<b>--help</b>` to any `<b>gh</b>` command (e.g., `<b>gh repo create --help</b>`). This utility is indispensable for understanding how to use `<b>gh</b>` functionalities directly from the terminal, eliminating the need to consult external documentation. It offers detailed explanations of command purposes, syntax, arguments, options, and often includes practical examples. The help system is context-aware, allowing users to retrieve general `<b>gh</b>` information or specific details for any `<b>gh</b>` subcommand. It is a fundamental component of the `<b>gh</b>` CLI, empowering users to efficiently interact with GitHub repositories, issues, pull requests, and more, all from the command line.


title: CAVEATS
content:
The command `<b>gh-help</b>` is not a standalone executable on most Linux systems; it primarily refers to the help functionality invoked through `<b>gh help</b>` or `<b>gh <command> --help</b>`. This functionality requires the GitHub CLI (`<b>gh</b>`) to be installed and configured on the system. The displayed help content is specific to the version of the `<b>gh</b>` CLI installed, so it may vary across different installations or updates.


title: GETTING HELP FOR FLAGS
content:
To view help specifically for the flags and options of a `<b>gh</b>` command, append `<b>--help</b>` directly to the command, for example: `<b>gh pr create --help</b>`. This provides a detailed breakdown of all available flags, their types, and descriptions relevant to that particular command.


title: INTERACTIVE HELP AND AUTOCOMPLETE
content:
The `<b>gh</b>` CLI often integrates well with shell autocompletion features (e.g., for Bash, Zsh, Fish), which can suggest commands and flags as you type. While not directly part of `<b>gh-help</b>`, this complements the help system by guiding users towards correct syntax and available options.


title: HISTORY
content:
The `<b>gh</b>` command-line interface, which includes the `<b>help</b>` functionality, was first publicly released in 2020. From its inception, a robust and integrated help system was a core design principle, following common CLI best practices established by tools like `<b>git</b>` and `<b>docker</b>`. The `<b>help</b>` command has consistently provided users with immediate access to documentation, evolving with the CLI's features to ensure up-to-date guidance for new commands and functionalities.


title: PARAMETERS
content:
<b>install <tool> [version]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specific version of a tool (e.g., ghc, cabal, stack, ghcjs). If no version is specified, the recommended version is installed.<br><br><b>set <tool> <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific installed version of a tool as the default for the current user.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available and currently installed versions of various Haskell tools.<br><br><b>upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades <i>ghcup</i> itself to the latest version or updates installed Haskell tools to their recommended versions.<br><br><b>rm <tool> [version]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more installed versions of a specified tool. If no version is given, it removes all installed versions of that tool.<br><br><b>cabal <args...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the <i>ghcup</i>-managed Cabal build tool with the provided arguments.<br><br><b>stack <args...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the <i>ghcup</i>-managed Stack build tool with the provided arguments.<br><br><b>tui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches an interactive Text User Interface (TUI) for easier visual management of tools and versions.<br><br><b>path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about how <i>ghcup</i> manages the system's PATH environment variable for its tools.<br><br><b>whereis <tool></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the full filesystem path to the currently active <i>ghcup</i>-managed executable for a given tool.<br><br><b>run <tool> <version> [args...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a specific, explicitly chosen version of a tool, overriding the default set version.<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows managing various configuration settings for <i>ghcup</i> itself, such as mirror URLs or download behavior.<br><br><b>help [command]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help information or detailed help for a specific <i>ghcup</i> command.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version number of the <i>ghcup</i> client.<br><br>


title: DESCRIPTION
content:
<i>ghcup</i> is a robust command-line tool designed to simplify the installation and management of the Haskell toolchain. This includes the Glasgow Haskell Compiler (GHC), the Cabal build tool, the Stack build tool, and GHCJS. It provides a unified interface for users to easily install specific versions, switch between them, upgrade existing components, and remove unwanted installations.<br><br>The primary goal of <i>ghcup</i> is to offer a consistent, cross-platform, and hassle-free experience for setting up and maintaining a Haskell development environment, handling dependencies and ensuring compatibility across different projects. It has become the recommended method for new and experienced Haskell developers to get started.


title: CAVEATS
content:
Initial setup and installations require active internet connectivity to download tool binaries.<br><i>ghcup</i> modifies shell configuration files (e.g., ~/.bashrc, ~/.zshrc) to ensure its managed tools are correctly added to the system's PATH. Users should be aware of these changes.<br>Successful installation of certain tools may depend on the presence of system-level build dependencies (e.g., GCC, make, curl, xz) which <i>ghcup</i> does not automatically install.<br>Primarily focuses on binary distributions. Building tools from source via <i>ghcup</i> is not its main use case.


title: PATH MANAGEMENT
content:
During its initial setup, <i>ghcup</i> typically prompts to modify your shell's configuration file (like ~/.bashrc or ~/.zshrc) to prepend its binary directory to your PATH environment variable. This ensures that the <i>ghcup</i>-managed versions of tools are found before any system-installed ones. After modification, you often need to source your shell configuration (e.g., <code>source ~/.bashrc</code>) or restart your terminal for changes to take effect.


title: NON-INTERACTIVE USAGE
content:
For scripting or automated environments, <i>ghcup</i> supports non-interactive installation. Options like <code>--no-modify-path</code>, <code>--no-install-ghc</code>, <code>--skip-update</code>, and <code>--verbose</code> can be used to control its behavior without user prompts. This is useful for CI/CD pipelines or reproducible development setups.


title: HISTORY
content:
<i>ghcup</i> emerged as a modern solution to the fragmented and often complex landscape of Haskell toolchain installation. Prior to its development, setting up a Haskell environment often involved manual installations, relying on potentially outdated system package managers, or using less comprehensive platform-specific installers. <i>ghcup</i> was designed to unify this experience, providing a consistent, cross-platform, and robust way to manage GHC, Cabal, and Stack. Its development has been community-driven, aiming to streamline the developer onboarding process and provide a reliable foundation for Haskell project management.


title: SEE ALSO
content:
cabal(1), stack(1), ghc(1), nvm(1) (Node Version Manager - conceptually similar), pyenv(1) (Python Version Manager - conceptually similar)


title: SYNOPSIS
content:
<b>gipddecode</b> [<i>OPTIONS</i>] [-i <i>TRACE_FILE</i>] [-o <i>OUTPUT_FILE</i>] [<i>BINARY_PATH</i>]


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the utility and exits.<br><br><b>-i <i>FILE</i>, --input <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file containing the raw Intel Processor Trace (IPT) data to be decoded. This can be a raw trace stream or a file generated by tools like <i>perf</i>.<br><br><b>-o <i>FILE</i>, --output <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file where the decoded instruction stream will be written. If not specified, output is typically sent to standard output (stdout).<br><br><b>-p <i>PATH</i>, --path <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a directory to the search path for executables and shared libraries. This is crucial for <b>gipddecode</b> to resolve instruction addresses to meaningful symbolic names (function names, variable names).<br><br><b>-s <i>CPU_ID</i>, --cpu <i>CPU_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the CPU ID for which the trace data should be decoded. Useful when the input trace file contains data from multiple CPUs.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output during the decoding process, providing more detailed information about the trace parsing.<br><br><b>-l <i>LEVEL</i>, --log-level <i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the verbosity level of the output. Higher levels provide more detailed information about the decoded trace.<br><br><b>-x, --no-ip-filtering</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables filtering of non-instruction pointer trace packets, displaying all raw trace events.<br><br><b>-c, --cycle-accurate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to perform cycle-accurate decoding, providing timestamps for each instruction if supported by the trace data and hardware.<br><br>


title: DESCRIPTION
content:
The <b>gipddecode</b> command is a specialized utility designed to decode raw Intel Processor Trace (IPT) data streams into human-readable instruction sequences. Intel Processor Trace is a CPU feature, introduced with Broadwell processors, that records program execution flow with minimal overhead, capturing branches, changes in instruction pointer, and other events. This raw trace data, often captured by tools like <i>perf</i> on Linux, is highly compressed and not directly readable. <br><br><b>gipddecode</b> processes this binary trace data, reconstructs the execution path, and displays the sequence of executed instructions, often including symbolic information if the corresponding executables and libraries are available. It is an invaluable tool for low-level debugging, reverse engineering, performance analysis (understanding hot paths, branch mispredictions), and security research, allowing developers and analysts to precisely observe the CPU's execution flow. Due to its specialized nature, <b>gipddecode</b> is typically part of Intel's developer tools, SDKs, or built from libraries like <i>libipt</i>, rather than being a standard command in typical Linux distributions.


title: CAVEATS
content:
<b>gipddecode</b> is not a standard, universally available Linux command. It typically needs to be installed as part of Intel's development toolchains (e.g., VTune Amplifier, Intel SDKs) or built from source (e.g., from the <i>libipt</i> project).<br><br>It requires a CPU with Intel Processor Trace (IPT) capabilities to generate the input trace data.<br><br>Effective use often depends on having the exact binaries and libraries that were executing during the trace capture, for proper symbol resolution. Without them, the output will only show raw addresses.


title: INTEL PROCESSOR TRACE (IPT)
content:
Intel Processor Trace is a hardware feature that records control-flow changes (branches, calls, returns, interrupts, etc.) and other events in a highly compressed binary format. It's used for detailed execution flow analysis without significantly impacting performance. <b>gipddecode</b> is one of the key tools for turning this raw, binary trace data into a human-readable stream of executed instructions.


title: USAGE WITH <I>PERF</I>
content:
While <b>gipddecode</b> is a standalone utility, its input trace data is often captured using the Linux <i>perf</i> tool. A common workflow involves recording trace data with <i>perf record -e intel_pt// <command></i>, which generates a <i>perf.data</i> file. Although <i>perf script</i> can often decode this data internally, <b>gipddecode</b> provides a dedicated interface for more specialized or raw processing of the underlying Intel PT stream extracted from such files or captured directly.


title: HISTORY
content:
The advent of Intel Processor Trace (IPT) technology, first introduced with Intel's Broadwell microarchitecture, enabled fine-grained, low-overhead instruction tracing at the hardware level. This capability created a need for specialized software tools to decode the highly compressed binary trace data generated by the CPU. <br><br>Utilities like <b>gipddecode</b> emerged to fill this role, often built upon underlying libraries such as <i>libipt</i> (the Intel Processor Trace Decoder Library), which provides the core decoding logic. Its development paralleled the integration of IPT support into debugging and profiling tools like <i>perf</i> on Linux and Intel's proprietary VTune Amplifier, becoming an essential component for detailed execution analysis on Intel platforms.


title: SYNOPSIS
content:
Git aliases are a feature managed primarily via the <b><I>git config</I></b> command. Below are common operations to manage aliases:<br><br><b><I>git config [--global | --local | --system] alias.&lt;name&gt; &lt;command&gt;</I></b><br>Define or update an alias named <i>&lt;name&gt;</i> to execute <i>&lt;command&gt;</i>.<br><br><b><I>git config [--global | --local | --system] --unset alias.&lt;name&gt;</I></b><br>Remove a previously defined alias.<br><br><b><I>git config [--global | --local | --system] --get-regexp alias.</I></b><br>List all defined aliases in the specified or default scope.


title: PARAMETERS
content:
<b>alias.<I>&lt;name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The configuration key specifying the alias. <i>&lt;name&gt;</i> is the desired shortcut name you'll use (e.g., <i>co</i> for <i>checkout</i>).<br><br><b><I>&lt;command&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Git command(s) or shell command string to be aliased. If the string starts with <i>!</i>, it will be executed as a shell command (e.g., <i>'!git status --short'</i>).<br><br><b>--global</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the configuration to the user's global Git configuration file (typically <i>~/.gitconfig</i>), affecting all Git repositories for that user.<br><br><b>--local</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the configuration only to the current repository's Git configuration file (<i>.git/config</i>). This is the default scope if no scope is specified.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the configuration to the system-wide Git configuration file (e.g., <i>/etc/gitconfig</i>), affecting all users and repositories on the system. Requires administrative privileges.<br><br><b>--unset</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>alias.&lt;name&gt;</i> to remove the specified alias from the configuration.<br><br><b>--get-regexp alias.</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all configuration entries that match the regular expression 'alias.', effectively displaying all defined Git aliases and their corresponding commands.<br><br>


title: DESCRIPTION
content:
Git aliases provide a powerful way to create custom shortcuts for longer Git commands or sequences of commands. They are defined using the <b><I>git config</I></b> command and stored in Git's configuration files (e.g., <i>~/.gitconfig</i> for global aliases, or <i>.git/config</i> for local repository aliases).<br><br>When you define an alias like <b><I>git config --global alias.co checkout</I></b>, you can then simply type <b><I>git co</I></b> instead of <b><I>git checkout</I></b>. Aliases can be simple command substitutions or execute complex shell commands by prefixing the aliased command with an exclamation mark (<b><I>!</I></b>). For example, <b><I>git config --global alias.st 'status -sb'</I></b> allows <b><I>git st</I></b> to show a short, branch-aware status. A shell alias like <b><I>git config --global alias.hist '!git log --pretty=format:"%h %ad | %s%d [%an]" --date=short'</I></b> executes a custom log format.<br><br>Using aliases significantly improves workflow efficiency, reduces typing, and allows users to personalize their Git experience to match their preferences and common operations. They are resolved before Git attempts to find a built-in command, making them highly effective for overriding or shortening existing commands.


title: CAVEATS
content:
<b>Resolution Order:</b> Git aliases are resolved before built-in Git commands. This means if you define an alias named 'status', it will override the default <b><I>git status</I></b> command when you type <b><I>git status</I></b>.<br><br><b>Shell Commands:</b> Aliases prefixed with <b><I>!</I></b> execute as shell commands, with their current working directory set to the top-level directory of the Git repository. Be cautious with complex shell scripts and ensure proper quoting to prevent unexpected behavior.<br><br><b>Security Considerations:</b> Running arbitrary shell commands via aliases can pose security risks if configurations are shared or if you clone untrusted repositories with potentially malicious aliases. Always review aliases from unknown sources.


title: GIT ALIASES VS. SHELL ALIASES
content:
It's important to distinguish between Git aliases and shell aliases. A <i>shell alias</i> (e.g., <b><I>alias gco='git checkout'</I></b> in Bash or Zsh) is defined in your shell's configuration and expands before the command is even passed to Git. It's purely a shell-level shortcut. A <i>Git alias</i>, conversely, is processed by Git itself. This means Git aliases are portable across different shells and systems (as long as Git is configured), and they can intelligently interact with Git's internal state (especially when used with the <b><I>!</I></b> prefix for shell commands within a Git context). Git aliases are generally preferred for Git-specific shortcuts.


title: PRACTICAL EXAMPLES OF GIT ALIASES
content:
Here are some common and highly useful Git aliases you can add to your global configuration (using <b><I>git config --global</I></b>):<br><b><I>git config --global alias.co checkout</I></b> (shorthand for checkout)<br><b><I>git config --global alias.br branch</I></b> (shorthand for branch)<br><b><I>git config --global alias.ci commit</I></b> (shorthand for commit)<br><b><I>git config --global alias.st 'status -sb'</I></b> (short status with branch info)<br><b><I>git config --global alias.unstage 'reset HEAD --'</I></b> (unstage files)<br><b><I>git config --global alias.last 'log -1 HEAD'</I></b> (show last commit)<br><b><I>git config --global alias.visual '!gitk'</I></b> (launches Gitk, if installed)<br><b><I>git config --global alias.alias '!git config --get-regexp alias.'</I></b> (a self-referential alias to list all your Git aliases!)


title: HISTORY
content:
The concept of Git aliases has been a fundamental part of Git from its early development, providing a flexible mechanism for users to customize their command-line interface. While there isn't a dedicated 'git-alias' command executable, the functionality has always been integral to personalizing and streamlining Git workflows via <b><I>git config</I></b>, reflecting Git's design philosophy of being highly configurable. This feature has evolved alongside Git's configuration system, allowing for increasing levels of customization and powerful scripting capabilities.


title: SYNOPSIS
content:
git check-attr [--all | --cached | --source | --stdin] &lt;attribute&gt;... &lt;path&gt;...<br>git check-attr [--litmus] &lt;attribute&gt; &lt;path&gt;<br>git check-attr --help


title: PARAMETERS
content:
<b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all attributes that are defined for the given paths.<br><br><b>--cached</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check attributes for the version of the paths in the index (staging area) rather than the working tree.<br><br><b>--source</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the source of the attribute definition (e.g., the <i>.gitattributes</i> file path) along with its value.<br><br><b>--stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read paths and attribute names from standard input, one per line. Each line should be in the format: <i>attribute path</i>.<br><br><b>--litmus</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret the given <i>attribute</i> as a boolean and output <b>true</b> or <b>false</b> based on its effective value for the <i>path</i>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the command.<br><br><b>&lt;attribute&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more attribute names to query (e.g., <i>text</i>, <i>binary</i>, <i>crlf</i>).<br><br><b>&lt;path&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths (files or directories) for which to check attributes.<br><br>


title: DESCRIPTION
content:
<i>git-check-attr</i> is a utility command used to inspect and verify the Git attributes assigned to files and directories within a repository. These attributes, defined in <i>.gitattributes</i> files (at various levels like project, user, or global), dictate how Git should handle certain file types or paths. Examples include <b>text</b>, <b>binary</b>, <b>diff</b>, <b>merge</b>, <b>crlf</b>, <b>export-ignore</b>, and custom attributes.<br><br>The command allows users to query the effective value of specific attributes for given paths, helping to diagnose issues related to line endings, diff behavior, or export filtering. It can report whether an attribute is <b>set</b>, <b>unset</b>, <b>true</b>, <b>false</b>, or <b>unspecified</b>. It also supports checking attributes for cached (indexed) paths, providing the source of an attribute definition, or performing litmus tests for boolean attributes. This tool is invaluable for understanding Git's behavior concerning file handling and ensuring attribute configurations are working as expected.


title: CAVEATS
content:
The command evaluates attributes based on the <i>.gitattributes</i> files found in the repository, <i>.git/info/attributes</i>, and the global attributes file. If an attribute is not explicitly defined for a path or inherits no value, its value might be <b>unspecified</b>. The <b>--cached</b> option is crucial when debugging issues related to staged content, as attributes can sometimes differ between the working tree and the index.


title: ATTRIBUTE VALUES
content:
The output for an attribute can be <b>set</b> (attribute is present, no specific value like <b>text</b>), <b>unset</b> (attribute is explicitly unset with <b>-attribute</b>), <b>true</b> (attribute has a boolean true value), <b>false</b> (attribute has a boolean false value), or <b>unspecified</b> (attribute is not defined for the path in any relevant <i>.gitattributes</i> file).


title: RESOLUTION ORDER
content:
Git resolves attributes from multiple sources in a specific order: <i>.git/info/attributes</i> (repository-specific, not tracked), then <i>.gitattributes</i> files in the repository hierarchy (from root down to the file's directory), and finally the file specified by <i>core.attributesfile</i> (global/user-specific, typically in your home directory).


title: HISTORY
content:
<i>git-check-attr</i> was introduced in Git 1.7.0.4. Its primary purpose was to provide a robust and scriptable way to query Git attributes, complementing the more passive nature of <i>.gitattributes</i> files and internal Git attribute processing. Over time, options like <b>--source</b> and <b>--litmus</b> were added to enhance its debugging capabilities and provide more detailed attribute insights.


title: PARAMETERS
content:
<b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the git-cola version information and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit, listing available command-line options.<br><br><b><b>--repo=&lt;dir&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the specified Git repository located at <i>&lt;dir&gt;</i> instead of the current directory. This is useful for launching git-cola for a specific project.<br><br><b><b>--amend</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launch the commit dialog with the 'amend' option pre-selected, allowing the user to modify the most recent commit.<br><br><b><b>--amend-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform an amend operation immediately without showing the commit dialog. This is useful for quickly amending changes to the last commit.<br><br><b><b>--status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the status window upon startup. This is the default behavior if no other view is specified.<br><br><b><b>--diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the diff viewer window upon startup, displaying differences between the working tree and the index, or between commits.<br><br><b><b>--branch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the branch management dialog upon startup, allowing users to create, delete, and switch branches.<br><br><b><b>--config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the configuration editor dialog upon startup, providing a GUI to manage git-cola and Git settings.<br><br><b><b>--init-db</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initialize a new Git repository in the current directory and then open it in git-cola. Useful for starting new projects.<br><br><b><b>--exec=&lt;command&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute an internal git-cola command directly, such as 'pull', 'push', or 'rebase'. This can be used for automation or specific actions.<br><br><b><b>--style=&lt;style&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the application GUI style, e.g., 'fusion', 'windows', 'gtk+'. This changes the visual theme of the application.<br><br><b><b>--prompt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force git-cola to prompt the user for a repository to open if one is not found in the current directory or specified via <b>--repo</b>.<br><br><b><b>--submodule</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat the current directory as a submodule, which can affect how certain Git operations are handled within git-cola.<br><br>


title: DESCRIPTION
content:
git-cola is a powerful yet simple graphical user interface (GUI) for Git. It provides a comprehensive set of features for interacting with Git repositories, designed for both novice and experienced users. Key functionalities include staging and unstaging changes, creating and amending commits, managing branches, performing merges and rebases, viewing diffs, and exploring repository history. git-cola emphasizes a streamlined workflow and ease of use, leveraging a clean interface built with Qt.<br><br>It is cross-platform, running on Linux, macOS, and Windows, and integrates seamlessly with the underlying Git command-line tool. Its flexibility allows users to configure various aspects of its behavior and appearance, making it adaptable to different preferences and workflows.


title: CAVEATS
content:
git-cola requires a functional Git installation on the system to operate. As a graphical user interface application, it is not suitable for scripting or use in headless server environments. While generally robust, performance might be affected in extremely large repositories or during very complex history manipulation operations. It also depends on Python and the PyQt5 library for its execution.


title: CONFIGURATION
content:
<i>git-cola</i> extensively uses Git's standard configuration mechanism (<code>git config</code>). Many aspects of its behavior, including default commit messages, integration with external tools, and appearance settings, can be customized globally or per-repository using configuration keys under the <code>cola.</code> namespace (e.g., <code>git config --global cola.auto-fetch true</code>).


title: KEYBOARD SHORTCUTS
content:
For enhanced productivity, <i>git-cola</i> provides a rich set of keyboard shortcuts for most common actions and navigation. These shortcuts are often displayed next to menu items, allowing power users to quickly perform operations without relying on mouse clicks.


title: EXTENSIBILITY WITH ACTIONS
content:
Users can extend <i>git-cola</i>'s functionality by defining custom 'actions'. These actions, configured via <code>git config</code>, appear in <i>git-cola</i>'s menus and can execute external scripts or commands, enabling deep integration with specialized workflows or tools.


title: HISTORY
content:
<i>git-cola</i> was created by David Aguilar, with its initial development dating back to late 2007 or early 2008. Since its inception, it has undergone continuous active development and maintenance, consistently adding new features, improving usability, and enhancing its integration with Git. Its development has focused on providing a powerful, intuitive, and cross-platform Git GUI that seamlessly complements the command-line Git tools, earning it a reputation as a reliable choice for developers who prefer a graphical interface for their Git workflows.


title: SYNOPSIS
content:
<br>The term "<I>git-contrib</I>" does not refer to a single executable command itself. Instead, it denotes a directory containing numerous independent Git-related utility scripts. Therefore, there is no universal synopsis for "<I>git-contrib</I>".<br><br>Each script within the <I>contrib</I> directory has its own unique syntax and options. To use a specific script, you generally invoke it directly by its name, often prefixed with its full path, or by using a Git alias if one has been configured.<br><br><b>General invocation pattern for a <I>contrib</I> script:</b><br><br><I>    /path/to/git-core/contrib/script-name [options] [arguments]</I><br><br><b>Example for a hypothetical <I>contrib</I> script:</b><br><br><I>    /usr/share/git-core/contrib/git-foo-bar --option-a value file.txt</I>


title: PARAMETERS
content:
<b><I>N/A - Varies per script</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The term "<I>git-contrib</I>" refers to a collection of numerous independent scripts, not a single command. As such, there are no universal parameters that apply across all of them.<br><br>Each script within the <I>contrib</I> directory defines its own specific command-line options and arguments. Users must consult the individual script's documentation or source code for its parameters.<br><br>


title: DESCRIPTION
content:
<br>The term "<I>git-contrib</I>" refers to a collection of community-contributed scripts and tools that extend Git's functionality beyond its core commands. These utilities are typically found in a dedicated directory within the Git installation, often located at paths like <I>/usr/share/doc/git-core/contrib/</I> or <I>/usr/share/git-core/contrib/</I>. They are developed and maintained by the Git community to address specific use cases, automate complex workflows, or provide specialized features that are not part of the official Git distribution.<br><br>Unlike core Git commands, scripts in the <I>contrib</I> directory are not officially supported or guaranteed to be stable across Git versions. However, many of them are widely used and can be incredibly valuable for developers. Users typically invoke these scripts by their full path, or by copying/symlinking them into their system's PATH, or by creating a Git alias for easier access. The <I>contrib</I> collection serves as a rich resource for advanced Git users looking for powerful, niche tools.


title: CAVEATS
content:
<br><b>•   <I>Unofficial Status</I></b>: Scripts in the <I>contrib</I> directory are not part of Git's core distribution and are not officially supported by the Git development team. They may not adhere to the same stability guarantees as core commands.<br><br><b>•   <I>Maintenance and Updates</I></b>: Their maintenance status can vary widely. Some scripts are actively maintained, while others might be outdated or abandoned. Compatibility with newer Git versions is not always guaranteed.<br><br><b>•   <I>Security Risks</I></b>: As these are third-party scripts, running them carries inherent risks. Always review the script's code before executing it, especially if obtained from an untrusted source, to prevent potential security vulnerabilities.<br><br><b>•   <I>Dependencies</I></b>: Many <I>contrib</I> scripts are written in shell, Perl, or Python and may rely on external tools or libraries that are not bundled with Git. Users might need to install additional dependencies for a script to function correctly.<br><br><b>•   <I>Availability</I></b>: The exact set of scripts available in the <I>contrib</I> directory can differ across Git distributions, operating systems, and Git versions. Some distributions might not include the <I>contrib</I> directory by default, or it might be in a different location.


title: COMMON CONTRIB SCRIPT EXAMPLES
content:
<br>While the contents vary, some notable types of scripts frequently found or discussed in the <I>git-contrib</I> collection include:<br><br><b>•   <I>git-subtree</I></b>: Manages subprojects in your repository by embedding them as subdirectories, offering an alternative to Git submodules.<br><b>•   <I>git-prompt.sh</I></b>: A popular script used for customizing shell prompts to display Git repository status information (branch, dirty state, etc.).<br><b>•   <I>git-gui</I></b> (often a separate package but originates from contrib spirit): A Tcl/Tk based graphical user interface for Git.<br><b>•   <I>git-send-email</I></b> (now often core, but historically a contrib or related idea): A tool for sending patch series via email, commonly used in open-source projects.<br><b>•   <I>git-browse</I></b>: Opens the current repository or a specific file in a web browser, often linking to a service like GitHub or GitLab.<br><b>•   <I>git-archive-zip</I></b>: Helps create zip archives of a Git repository, potentially handling submodules or other complexities.


title: HISTORY
content:
<br>The concept of a "<I>contrib</I>" (contributions) directory within the Git project arose early in its development. It served as a pragmatic solution to accommodate useful tools and scripts that extended Git's capabilities without burdening the core project with their maintenance or making them official, fully supported commands.<br><br>Linus Torvalds, the creator of Git, famously emphasized a minimalist approach for the core Git toolset. The <I>contrib</I> directory became a natural home for "nice-to-have" utilities that were too specialized, too experimental, or too niche to be integrated directly into the main Git executable. This allowed the community to innovate and share solutions rapidly, providing a testing ground for new ideas. Over time, some highly successful <I>contrib</I> scripts, like <I>git-subtree</I> or <I>git-gui</I>, gained significant adoption and sometimes even saw parts of their functionality or concepts influence new core Git commands, or were themselves later integrated into the main Git distribution as optional packages.


title: PARAMETERS
content:
<b>approve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Approves credentials previously requested by <i>git credential fill</i>. This informs the credential helper that the credentials provided by a prior `get` operation were successfully used and should be stored for future use.<br><br><b>reject</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rejects credentials previously requested by <i>git credential fill</i>. This informs the credential helper that the credentials provided by a prior `get` operation failed, and should be erased or marked as invalid.<br><br><b>fill</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests credentials from the configured helper and prints them to standard output. This subcommand is largely deprecated in modern Git versions, as Git now interacts directly with the credential helper using the `get` protocol, but it remains for compatibility.<br><br>


title: DESCRIPTION
content:
The <b>git-credential</b> command provides an interface for Git to securely store and retrieve user credentials, such as usernames and passwords, required for authenticating with remote repositories over HTTP/HTTPS. It is not typically invoked directly by users but is instead called by Git itself when it needs authentication information.<br><br>This system allows Git to interact with various credential helpers (like <i>store</i>, <i>cache</i>, <i>osxkeychain</i>, <i>wincred</i>, or <i>libsecret</i>) that manage the actual storage and retrieval of credentials. By standardizing the communication protocol (using stdin/stdout for `get`, `store`, and `erase` operations), <b>git-credential</b> ensures a consistent and extensible way for Git to handle authentication seamlessly across different platforms and security requirements, avoiding repetitive credential prompts.<br><br>When Git needs credentials, it asks the configured helper to `get` them. When credentials are successfully used, Git tells the helper to `store` them. If credentials fail, Git tells the helper to `erase` them.


title: CAVEATS
content:
<b>git-credential</b> is primarily an internal interface; direct user invocation is rare. Most interactions are managed by Git automatically based on the `credential.helper` configuration.<br><br>Security implications vary greatly depending on the chosen credential helper. Some helpers store credentials in plain text (e.g., <i>store</i>), while others leverage OS-level secure storage (e.g., <i>osxkeychain</i>, <i>wincred</i>, <i>libsecret</i>). Users should choose a helper that aligns with their security requirements.<br><br>The `fill` subcommand is deprecated; Git now communicates directly with credential helpers via the `get` protocol for better control and flexibility.


title: PROTOCOL
content:
The <b>git-credential</b> interface operates on a simple text-based protocol over standard input/output. Git passes key-value pairs (like `protocol=https`, `host=github.com`, `username=myuser`, `path=/repo.git`) to the helper on stdin. The helper responds on stdout with requested information or status. The primary operations are:<br><ul><li><b>get</b>: Git asks the helper for credentials. The helper prints `username=...` and `password=...` to stdout if found.</li><li><b>store</b>: Git provides credentials (e.g., after a successful authentication) for the helper to save.</li><li><b>erase</b>: Git asks the helper to remove stored credentials (e.g., after an authentication failure).</li></ul>


title: CONFIGURATION
content:
The behavior of the credential system is controlled by the `credential.helper` configuration variable in Git. This variable specifies which credential helper Git should use. For example:<br><i>git config --global credential.helper store</i><br>This command sets the global credential helper to `store`, which saves credentials in a plain-text file. Other options include `cache` (stores in memory for a short duration), `osxkeychain`, `wincred`, or `libsecret` for more secure system-level storage.


title: HISTORY
content:
The Git credential system was introduced around Git version 1.7.9 (released in 2012) to provide a standardized, pluggable mechanism for handling authentication details. Prior to this, users often relied on manually managing credentials in `~/.netrc` files or being prompted repeatedly.<br><br>The initial implementations included simple helpers like `store` and `cache`. Over time, more secure and platform-specific helpers (like `osxkeychain`, `wincred`, and `libsecret`) were developed to integrate with native operating system credential managers, significantly enhancing security and user experience. The internal `fill` subcommand, while still available, has been largely superseded by Git's direct communication with helpers for improved protocol control.


title: SEE ALSO
content:
git-config(1), git-credential-store(1), git-credential-cache(1), git-credential-osxkeychain(1), git-credential-wincred(1), git-credential-libsecret(1)


title: SYNOPSIS
content:
<i>git-credential-cache</i> [--timeout <seconds>] [--socket <path>] <b><store|get|erase></b><br>(Note: <i>git-credential-cache</i> is usually invoked by Git itself, not directly by users.)


title: PARAMETERS
content:
<b><b>--timeout</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the duration (in seconds) for which credentials will be cached. After this period, the credentials expire and Git will prompt again. The default is 900 seconds (15 minutes).<br><br><b><b>--socket</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the Unix domain socket path used for communication with the cache daemon. This allows multiple processes to share the same cache instance. If not specified, a default path in the user's temporary directory is used.<br><br>


title: DESCRIPTION
content:
<i>git-credential-cache</i> is a Git credential helper that temporarily stores credentials in memory for a specified duration, typically to avoid repeatedly prompting the user for authentication. When Git needs credentials (e.g., for `http(s)` or `ftp` operations), it invokes configured credential helpers. If <i>git-credential-cache</i> is configured, it will intercept the credentials after the first successful authentication and store them in a daemon process running in the background. For subsequent requests within the configured timeout period, it will provide the cached credentials, eliminating the need for the user to re-enter their username and password or token.<br><br>The default timeout is 15 minutes (900 seconds). This helper significantly improves the user experience during a typical Git working session by reducing authentication friction. The credentials are held in plaintext within the daemon's memory, making it important to understand the security implications, though the short-lived nature of the cache mitigates most persistent risks.


title: CAVEATS
content:
<I>Security Implications</I>: Credentials are held in plain text within the memory of the <i>git-credential-cache--daemon</i> process. While the short timeout period reduces the risk of long-term exposure, an attacker with access to the system's memory or the ability to inspect running processes could potentially retrieve these credentials during the active caching period.<br><br><I>Daemon Process</I>: The helper operates by launching a background daemon process (<i>git-credential-cache--daemon</i>) that manages the cache. This daemon remains active until the cache expires or it is explicitly told to exit.<br><br><I>Shared Cache</I>: All Git repositories on the system (or within the user's environment) that are configured to use <i>git-credential-cache</i> will share the same credential cache instance, potentially leading to conflicts if different repositories require different credentials for the same remote URL.


title: CONFIGURATION
content:
To enable <i>git-credential-cache</i> for your repositories, you typically configure it using Git's configuration system: <br><code>git config --global credential.helper cache</code><br>This command adds `cache` to your global credential helpers. You can also specify a timeout:<br><code>git config --global credential.helper 'cache --timeout=3600'</code>


title: CLEARING THE CACHE
content:
To manually clear the cached credentials and stop the daemon process, you can run:<br><code>git credential-cache exit</code><br>This command signals the running daemon to terminate and clear its stored credentials.


title: HOW IT WORKS INTERNALLY
content:
When Git needs credentials, it launches the configured <i>git-credential-cache</i> helper. The helper then communicates with a background daemon process (<i>git-credential-cache--daemon</i>) via a Unix domain socket (or equivalent on Windows). The daemon handles the actual storage, retrieval, and expiration of credentials.


title: HISTORY
content:
The <i>git-credential-cache</i> helper was introduced as part of Git's broader credential management system, designed to make authentication more convenient for users without storing sensitive information persistently on disk (unlike <i>git-credential-store</i>). It was developed to address the common pain point of repeated password prompts during intensive Git usage, offering a balanced approach between convenience and security by keeping credentials in memory only for a limited duration. Its implementation reflects the evolving needs for secure and user-friendly authentication in distributed version control.


title: SYNOPSIS
content:
<b>git-credential-cache--daemon</b> [<b>--timeout=</b><i>&lt;seconds&gt;</i>] <i>&lt;socket-path&gt;</i>


title: PARAMETERS
content:
<b><b>--timeout=</b><i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the number of seconds the daemon should remain idle before exiting. If not provided, it typically defaults to a value configured by <b>credential.helperTimeout</b> (e.g., 900 seconds or 15 minutes).</i><br><br><b><i>&lt;socket-path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The mandatory path to the Unix domain socket that the daemon will create and listen on for incoming credential requests from other Git processes. This path is usually unique to the user's session and managed by the parent <b>git-credential-cache</b> process.</i><br><br>


title: DESCRIPTION
content:
<i>The <b>git-credential-cache--daemon</b> command is an internal helper process launched by <b>git-credential-cache</b>. Its primary function is to provide a persistent, in-memory cache for Git credentials, typically HTTP or HTTPS passwords, across multiple Git operations within a user session. By running in the background, it avoids the need for users to repeatedly enter their credentials when performing operations like push or pull against remote repositories that require authentication. The daemon communicates with other Git processes via a Unix domain socket. It is designed to automatically terminate after a period of inactivity, configurable via the <b>credential.helperTimeout</b> Git configuration option. Users generally do not interact with this command directly; it is managed automatically by the higher-level <b>git-credential-cache</b> helper.</i>


title: CAVEATS
content:
<i><br><b>Security:</b> The daemon holds credentials in memory. While communication is via a Unix domain socket with appropriate permissions, users should be aware that credentials are in a persistent process for the configured timeout.<br><b>Direct Invocation:</b> This command is not intended for direct user invocation. It is an internal component of Git's credential helper system and is managed automatically by <b>git-credential-cache</b>. Attempting to run it manually without proper setup may lead to unexpected behavior.</i>


title: <I>PURPOSE AND LIFETIME</I>
content:
<i>The daemon runs as a background process, typically launched by the <b>git credential-cache</b> helper when no daemon is already running and a credential is requested. It will exit automatically after its configured timeout period (defaulting to 15 minutes, or as set by <b>credential.helperTimeout</b> in Git configuration) if no new credential requests are received. This ensures that sensitive credentials are not held in memory indefinitely.</i>


title: <I>COMMUNICATION MECHANISM</I>
content:
<i>Communication between Git processes (which use the <b>git credential-cache</b> helper) and the daemon occurs via a Unix domain socket specified by the <b>&lt;socket-path&gt;</b> argument. This method provides a secure and efficient inter-process communication (IPC) channel on local systems, restricting access to processes with appropriate permissions.</i>


title: HISTORY
content:
<i>The Git credential helper system was introduced to provide a flexible way to handle various authentication methods beyond SSH keys, particularly for HTTP/HTTPS protocols. The caching daemon, <b>git-credential-cache--daemon</b>, was developed as part of this system to enhance user experience by reducing the frequency of password prompts within a short timeframe. It became a standard component for managing temporary credential storage, preventing repetitive credential entry and improving workflow efficiency for users interacting with remote Git repositories.</i>


title: SYNOPSIS
content:
<b>git credential-store</b> <operation><br>This helper is invoked by Git itself, not typically by the user directly. Git communicates with it via standard input and output.<br>The <code>--file</code> option for specifying the credentials file path is usually configured via <i>git config</i>.


title: PARAMETERS
content:
<b>get</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the helper to retrieve credentials for a given URL. Git provides the URL and other information on stdin, and expects credentials on stdout if found.<br><br><b>store</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the helper to store credentials. Git provides the credentials (protocol, host, username, password, etc.) on stdin for the helper to save.<br><br><b>erase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the helper to erase stored credentials for a given URL. Git provides the URL on stdin.<br><br><b>--file=&lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Configured via git config)</i> Specifies the file path where credentials are stored. Defaults to a standard location (e.g., <code>~/.git-credentials</code>). This is typically set using <code>git config credential.store.file &lt;path&gt;</code> rather than as a command-line argument to the helper.<br><br>


title: DESCRIPTION
content:
<i>git-credential-store</i> is a Git credential helper that saves and retrieves authentication credentials (like usernames and passwords) for Git repositories. It works by writing these credentials to a plain-text file on the local filesystem. This helper is commonly used to avoid repeatedly typing credentials when interacting with remote HTTP/HTTPS repositories. When Git needs credentials, it asks configured helpers; <i>git-credential-store</i> will look up the credentials in its file. When Git successfully authenticates, it can provide the credentials to <i>git-credential-store</i> to save them for future use. While convenient for persistence, its primary drawback is storing sensitive information unencrypted, making it a security risk if the file system is not adequately secured.


title: CAVEATS
content:
<i>git-credential-store</i> stores sensitive authentication credentials in a plain-text file. This poses a significant security risk as anyone with read access to this file can access the credentials. It is not recommended for use on shared systems or in environments where the filesystem's security cannot be guaranteed. Consider using more secure credential helpers like <i>osxkeychain</i> or <i>wincred</i> on supported platforms, or <i>cache</i> for short-term in-memory storage, if plain-text storage is a concern.


title: CONFIGURATION AND USAGE
content:
To enable <i>git-credential-store</i>, you typically configure Git using <i>git config</i>.<br>First, set the helper globally: <code>git config --global credential.helper store</code><br>Optionally, you can specify a custom file path for storing credentials:<br><code>git config --global credential.store.file ~/.my-custom-credentials</code><br>Once configured, Git will automatically use this helper to save new credentials after a successful push/pull and retrieve them when needed, eliminating the need for manual entry.


title: CREDENTIALS FILE FORMAT
content:
The <i>git-credential-store</i> file is a plain-text file where each line represents a set of credentials for a specific URL. The format is a URL with key-value pairs appended as query parameters. For example:<br><code>https://user:password@example.com</code><br>or more explicitly:<br><code>protocol=https<br>host=example.com<br>username=user<br>password=password</code><br>This simple format makes it easy to inspect (though not recommended for security reasons) and parse.


title: HISTORY
content:
The Git credential helper mechanism was introduced to address the problem of repeatedly entering authentication details for remote repositories. <i>git-credential-store</i> emerged as one of the simplest and most portable implementations, providing basic persistence by writing credentials to a flat file. Its design prioritizes simplicity and broad compatibility across different operating systems, despite the inherent security trade-off of storing sensitive information unencrypted. It has been a standard helper since its introduction as part of the broader credential management framework in Git.


title: SEE ALSO
content:
git(1), git-credential(7), git-config(1), git-credential-cache(1), git-credential-osxkeychain(1), git-credential-wincred(1)


title: PARAMETERS
content:
<b><I>commit-ish</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Git commit object (e.g., hash, branch name, tag, or other Git reference) to be exported as a CVS changeset. The command analyzes the differences introduced by this commit relative to its first parent (or an empty tree for the initial commit) to generate corresponding CVS operations.<br><br>


title: DESCRIPTION
content:
The <b>git-cvsexportcommit</b> command is an internal helper utility used by the <I>git-remote-cvs</I> bridge to export a single Git commit as a series of CVS operations. It takes a Git commit object and translates its changes&mdash;including additions, deletions, modifications, and directory changes&mdash;into a format suitable for CVS. This process involves determining the differences between the commit's tree and its first parent's tree (or an empty tree for the initial commit) and then generating the necessary <I>cvs add</I>, <I>cvs remove</I>, <I>cvs update</I>, and <I>cvs commit</I> commands. It ensures that the Git history can be accurately represented in a CVS repository, facilitating two-way synchronization between Git and CVS. Users typically interact with <I>git-remote-cvs</I> directly, which invokes <I>git-cvsexportcommit</I> behind the scenes.


title: CAVEATS
content:
<b>Internal Command</b>: This command is not intended for direct end-user interaction. It is an internal plumbing command primarily invoked by the <I>git-remote-cvs</I> utility.<br><br><b>CVS Limitations</b>: CVS has inherent limitations compared to Git, such as lack of atomic renames, inability to track empty directories, and different handling of merge conflicts. These differences can lead to imperfect or lossy translation of complex Git history into CVS.<br><br><b>Performance</b>: Exporting commits, especially large ones with many file changes, can be slow due to the nature of CVS operations which often involve file-by-file processing.<br><br><b>Dependency</b>: Requires a properly configured and accessible CVS client and repository.<br><br><b>Compatibility</b>: The <I>git-cvsbridge</I> project, which includes this command, might not be actively developed or maintained for all Git versions or operating systems, potentially leading to compatibility issues.


title: PURPOSE AND WORKFLOW
content:
The primary purpose of <I>git-cvsexportcommit</I> is to act as a crucial link in the push operation from a Git repository to a CVS repository via <I>git-remote-cvs</I>. When a user pushes changes from Git, <I>git-remote-cvs</I> identifies the Git commits that need to be transferred to CVS. For each such commit, it invokes <I>git-cvsexportcommit</I>, passing the commit ID. This command then calculates the necessary CVS operations (adds, removes, modifications) required to represent that Git commit's changes in the CVS repository. These operations are then executed against the CVS repository, effectively synchronizing the Git commit's state with CVS.


title: UNDERLYING MECHANISM
content:
<I>git-cvsexportcommit</I> works by performing a <I>git diff-tree</I> operation between the specified commit and its immediate parent (or the empty tree for the initial commit). The output of this diff, which details file changes, additions, and deletions, is then parsed. Based on this information, the command generates the appropriate sequence of <I>cvs</I> commands. This includes <I>cvs add</I> for new files, <I>cvs remove</I> for deleted files, and <I>cvs commit</I> for modified files, along with directory updates. The commit message and author/committer information from Git are also translated for the CVS commit.


title: HISTORY
content:
The <I>git-cvsexportcommit</I> command emerged as a component of the broader <I>git-cvsbridge</I> project, designed to provide a two-way bridge between Git and CVS repositories. Its development was driven by the need to facilitate migration from CVS to Git, as well as to enable ongoing interoperability for projects that still relied on CVS while some contributors preferred Git. Initially, such bridge components were often implemented as shell scripts, leveraging existing command-line tools. While CVS usage has declined, the <I>git-cvsbridge</I> and its utilities like <I>git-cvsexportcommit</I> remain important for legacy system integration and historical data access.


title: SYNOPSIS
content:
<b>git-daemon</b> [<i>--help</i> | <i>--version</i> | <i>--usage</i>]<br><b>git-daemon</b> [<i>--base-path=&lt;path&gt;</i>] [<i>--port=&lt;port&gt;</i>] [<i>--listen=&lt;host-or-ip&gt;</i>] [<i>--syslog</i> | <i>--log-output</i>] [<i>--max-connections=&lt;n&gt;</i>] [<i>--timeout=&lt;n&gt;</i>] [<i>--initd</i> | <i>--inetd</i>] [<i>--user=&lt;user&gt;</i>] [<i>--group=&lt;group&gt;</i>] [<i>--enable=&lt;service&gt;</i>] [<i>--disable=&lt;service&gt;</i>] [<i>--verbose</i>] [<i>--export-all</i>] [<i>--upload-pack</i> | <i>--no-upload-pack</i>] [<i>--upload-archive</i> | <i>--no-upload-archive</i>] [<i>--receive-pack</i> | <i>--no-receive-pack</i>] [<i>--strict-paths</i>] [<i>--interpolated-path=&lt;path&gt;</i>] [<i>--informative-errors</i>] [<i>--allow-override=&lt;service&gt;</i>] [<i>--forbid-override=&lt;service&gt;</i>] [<i>&lt;directory&gt;</i>]


title: PARAMETERS
content:
<b><i>--base-path=&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a base path for repositories. Clients must specify a path relative to this base path. This is useful for restricting access to a specific directory.<br><br><b><i>--port=&lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Listens on the specified port instead of the default Git protocol port (9418).<br><br><b><i>--listen=&lt;host-or-ip&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Listens on the specified host or IP address. By default, it listens on all available interfaces.<br><br><b><i>--export-all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows serving all repositories that <b>do not</b> have the <i>daemon.uploadpack</i> config variable explicitly set to <i>false</i>. Without this option, only repositories with <i>daemon.uploadpack=true</i> or a <i>git-daemon-export-ok</i> file are served.<br><br><b><i>--enable=&lt;service&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the specified service (e.g., <i>upload-pack</i>, <i>upload-archive</i>). By default, only <i>upload-pack</i> is enabled for exportable repositories.<br><br><b><i>--disable=&lt;service&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the specified service. This overrides any <i>--enable</i> or configuration settings.<br><br><b><i>--syslog</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs messages to syslog instead of standard error.<br><br><b><i>--log-output</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs messages to standard error. This is the default unless <i>--inetd</i> or <i>--syslog</i> is used.<br><br><b><i>--max-connections=&lt;n&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of concurrent connections the daemon will handle. New connections are rejected once this limit is reached.<br><br><b><i>--timeout=&lt;n&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of seconds to wait for a new connection or for an idle client to become active. After this time, the connection is dropped.<br><br><b><i>--initd</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the daemon in a way suitable for an <i>init</i> script, detaching from the controlling terminal and listening on the configured port. This is for standalone daemon operation.<br><br><b><i>--inetd</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the daemon in a way suitable for <i>inetd</i> or <i>xinetd</i>. It expects to read from standard input and write to standard output. This mode handles a single connection and then exits.<br><br><b><i>--user=&lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the user ID to <i>&lt;user&gt;</i> after binding the listening socket. Requires root privileges to set up.<br><br><b><i>--group=&lt;group&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the group ID to <i>&lt;group&gt;</i> after binding the listening socket. Requires root privileges to set up.<br><br><b><i>--verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints more detailed diagnostic information to the log output.<br><br>


title: DESCRIPTION
content:
The <b>git-daemon</b> command provides a simple, lightweight way to serve Git repositories over the unauthenticated Git protocol (port 9418 by default). It is primarily used for providing public, read-only access to repositories, such as those found in many open-source projects. Unlike HTTP or SSH, the Git protocol is designed specifically for Git, offering high performance and low overhead for anonymous clones and fetches.<br><br>When running, <b>git-daemon</b> listens for incoming connections and, upon request, serves content from specified repositories. For a repository to be served, it must be explicitly marked as exportable. This is typically done by setting the <i>daemon.uploadpack</i> configuration variable to <i>true</i> within the repository's configuration, or by placing a <i>git-daemon-export-ok</i> file at the root of the repository. Clients connect using <b>git clone git://hostname/path/to/repo.git</b>.<br><br><b>git-daemon</b> can run as a standalone process (often started from an <i>init</i> script), or it can be managed by a 'super-server' like <i>inetd</i> or <i>xinetd</i>, which spawns an instance of the daemon for each incoming connection. It does not provide any authentication or encryption, making it suitable only for publicly accessible data where security is not a primary concern for data in transit.


title: CAVEATS
content:
<b>git-daemon</b> offers only unauthenticated, unencrypted, read-only access to Git repositories. This implies several caveats:<br><br><ul><li><b>No Authentication:</b> Any client can connect and clone/fetch data from exposed repositories. It is unsuitable for private repositories or sensitive data.</li><li><b>No Encryption:</b> Data transfer occurs in plaintext over the network. Malicious actors could intercept and read the data.</li><li><b>Read-Only:</b> Pushing changes back to the server is not supported via <b>git-daemon</b>. For write access, an SSH-based or HTTP/S-based Git server is required.</li><li><b>Repository Export Configuration:</b> Repositories are not served by default. They must be explicitly marked for export either by having a <i>git-daemon-export-ok</i> file or by setting <i>daemon.uploadpack=true</i> in their configuration. Care must be taken not to accidentally expose unintended repositories, though the <i>--export-all</i> option can override this default behavior.</li></ul>


title: REPOSITORY EXPORT CONFIGURATION
content:
For a repository to be served by <b>git-daemon</b>, it must be explicitly configured for export. There are two primary ways to do this:<br><br><ul><li><b><i>git-daemon-export-ok</i> file:</b> Placing an empty file named <i>git-daemon-export-ok</i> in the root directory of the Git repository will mark it as exportable. This is a simple, direct method.</li><li><b><i>daemon.uploadpack</i> config:</b> Setting the Git configuration variable <i>daemon.uploadpack</i> to <i>true</i> within the repository's <i>.git/config</i> file enables the <i>upload-pack</i> service for that repository. This is the more modern and flexible approach. Similarly, <i>daemon.uploadarchive=true</i> enables the <i>upload-archive</i> service.</li></ul>The <i>--export-all</i> command-line option for <b>git-daemon</b> overrides these per-repository settings, allowing all repositories (that don't explicitly forbid it with <i>daemon.uploadpack=false</i>) under the specified base path to be served.


title: RUNNING AS A SERVICE
content:
<b>git-daemon</b> can be run in two main modes:<br><br><ul><li><b>Standalone Daemon:</b> Using the <i>--initd</i> option, <b>git-daemon</b> can run as a persistent background process. This is suitable for scenarios where the daemon needs to be constantly running, such as when configured via a system's <i>init</i> or <i>systemd</i> scripts.</li><li><b>Super-server (inetd/xinetd):</b> Using the <i>--inetd</i> option, <b>git-daemon</b> can be spawned on demand by a super-server like <i>inetd</i> or <i>xinetd</i>. In this mode, it handles a single connection and then exits. This is useful for managing resource usage and connection limits, especially when connections are infrequent.</li></ul>


title: HISTORY
content:
<b>git-daemon</b> is one of the original methods for serving Git repositories over the network, introduced very early in Git's development alongside SSH-based access. Its design prioritizes simplicity and performance for anonymous, read-only distribution of code. It leverages a custom, lightweight protocol that is highly optimized for Git's data transfer needs. While more feature-rich Git hosting solutions (like GitWeb, Git-HTTP, or full-fledged Git platforms) have emerged, <b>git-daemon</b> remains a fundamental tool for providing raw, low-overhead public access to Git repositories, especially in scenarios where high-volume anonymous cloning is desired without the overhead of HTTP or SSH server stacks.


title: SYNOPSIS
content:
<br><b>For local branches:</b><br><code>git branch -d <I>branch-name</I></code><br><code>git branch -D <I>branch-name</I></code><br><b>For remote branches:</b><br><code>git push <I>remote-name</I> --delete <I>branch-name</I></code><br><i>(or equivalently:</i> <code>git push <I>remote-name</I> :<I>branch-name</I></code><i>)</i>


title: PARAMETERS
content:
<b>-d or --delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the branch specified by <I>branch-name</I> if it has been fully merged into its upstream branch (or <code>HEAD</code> if no upstream is set). This is the 'safe' way to delete a local branch.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the deletion of the branch specified by <I>branch-name</I>, regardless of its merged status. This is useful for discarding unmerged feature branches or branches that are no longer needed. Alias for <code>--delete --force</code>.<br><br><b>--delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <code>git push</code>, this option deletes the specified branch on the remote repository. It sends a command to the remote to remove the branch reference.<br><br><b><I>branch-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the local or remote branch to be deleted. This argument is mandatory for all deletion commands.<br><br><b><I>remote-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the remote repository (e.g., <code>origin</code>) from which the branch should be deleted. This argument is used with <code>git push --delete</code>.<br><br>


title: DESCRIPTION
content:
The term 'git-delete-branch' commonly refers to the process of removing branches from a Git repository. Git provides distinct commands for deleting local branches and remote branches, each with options for safe or forceful removal. For local branches, <code>git branch -d</code> offers a safe deletion, only proceeding if the branch has been fully merged into its upstream or <code>HEAD</code>. This prevents accidental loss of unmerged work. Conversely, <code>git branch -D</code> (uppercase D) forces the deletion of a local branch, even if it contains unmerged commits. This is useful for discarding experimental or abandoned feature branches. Deleting remote branches requires interaction with the remote repository using <code>git push --delete</code>. This command sends a signal to the remote to remove the specified branch. After a remote branch is deleted, you may need to prune your local remote-tracking branches to reflect the changes. It's crucial to understand these distinctions to manage your repository's branch history effectively and avoid losing valuable work.


title: CAVEATS
content:
<ul><li>You cannot delete the Git branch you are currently checked out on. You must first switch to another branch.</li><li>Using <code>git branch -D</code> on an unmerged branch will permanently discard any commits unique to that branch. Ensure you no longer need the work before using this option.</li><li>Deleting a remote branch using <code>git push --delete</code> only removes the branch from the remote repository. Your local repository will still have a remote-tracking branch reference (e.g., <code>origin/my-feature</code>) until you prune it (e.g., with <code>git fetch --prune</code> or <code>git remote prune <I>remote-name</I></code>).</li><li>Be cautious when deleting branches, especially remote ones, as it affects shared history and collaborators.</li></ul>


title: DELETING LOCAL BRANCHES
content:
To remove a local branch, use <code>git branch -d <I>branch-name</I></code> for a safe deletion; Git will only delete it if it's fully merged into your current <code>HEAD</code> or its upstream. If the branch has unmerged changes or you wish to force its removal regardless of merge status, use <code>git branch -D <I>branch-name</I></code>. This is common for experimental branches that are no longer relevant.


title: DELETING REMOTE BRANCHES
content:
To delete a branch from a remote repository (e.g., <code>origin</code>), use the command <code>git push <I>remote-name</I> --delete <I>branch-name</I></code>. For example, <code>git push origin --delete feature/login-v1</code>. After this operation, the remote branch will be removed from the shared repository. Your local repository might still show a stale remote-tracking branch; to clean this up, run <code>git fetch --prune</code> or <code>git remote prune <I>remote-name</I></code>.


title: HISTORY
content:
Git's branch management, including deletion, has been a core feature since its inception. The <code>git branch -d</code> and <code>-D</code> options were designed to offer both cautious and forceful deletion capabilities, catering to different workflow needs. The <code>git push --delete</code> syntax was later introduced to simplify the process of removing remote branches, replacing earlier, less intuitive methods like <code>git push <I>remote-name</I> :<I>branch-name</I></code> (pushing an empty ref to delete). This evolution reflects Git's continuous effort to provide more user-friendly and explicit commands for common tasks.


title: SYNOPSIS
content:
<b>git delete-squashed-branches</b> [<b>-d</b>|<b>--dry-run</b>] [<b>-f</b>|<b>--force</b>] [<b>-r</b>|<b>--remote</b>] [<b>-b</b> <i>&lt;base-branch&gt;</i>|<b>--base</b>=<i>&lt;base-branch&gt;</i>]


title: PARAMETERS
content:
<b><b>-d</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows which branches <i>would</i> be deleted without actually deleting them.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes branches without prompting for confirmation.<br><br><b><b>-r</b>, <b>--remote</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Also deletes the corresponding remote tracking branch (e.g., <i>origin/feature-branch</i>) in addition to the local one.<br><br><b><b>-b</b> <i>&lt;base-branch&gt;</i>, <b>--base</b>=<i>&lt;base-branch&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the base branch to check against for squashed merges. Defaults typically to <i>main</i> or <i>master</i>.<br><br>


title: DESCRIPTION
content:
This utility script identifies and removes local Git branches that have been squashed and merged into a specified base branch (e.g., <i>main</i> or <i>master</i>). It's particularly useful after a common Git workflow where feature branches are squashed into a single commit before being merged, leaving no direct merge history for the feature branch.<br><br>The script helps clean up stale local branches, distinguishing them from branches that were fully merged with a merge commit, or those that still contain unique unmerged work. It often includes a dry-run option to preview deletions and a confirmation prompt for safety. This unofficial command streamlines repository management by automatically clearing branches whose work has been incorporated into the main development line, even when the original branch history isn't preserved through a traditional merge.


title: CAVEATS
content:
<b>Not a standard Git command:</b> This is a community-driven script, so its exact behavior and options may vary depending on the specific implementation used.<br><b>Reliance on history:</b> The script relies on Git's commit history. If history has been re-written (e.g., with <b>git rebase -i</b>), the script might not accurately identify squashed branches or could potentially delete branches that still contain unique work.<br><b>False positives/negatives:</b> While designed to be smart, it's possible for the script to misidentify branches as squashed, or miss truly squashed branches, especially in complex or unusual repository states. Always use the <b>--dry-run</b> option first.<br><b>Irreversible deletion:</b> Deleting branches is generally irreversible without manual intervention or recovery from backups.


title: HOW IT WORKS (COMMON LOGIC)
content:
Typically, the script identifies branches whose commits are fully contained within the history of the base branch, even if there isn't a direct merge commit (which is characteristic of a squash merge). It might do this by checking if <b>git log &lt;feature-branch&gt; ^&lt;base-branch&gt;</b> shows no unique commits, or by using other more complex Git plumbing commands to verify ancestry and content. It usually excludes the currently checked-out branch and branches configured as protected.


title: HISTORY
content:
This is not an official Git command with a formal history in the Git project. Instead, <b>git-delete-squashed-branches</b> refers to a common pattern of community-developed shell scripts or aliases. These scripts emerged from the need to manage local branches effectively in workflows that frequently use squash merges (e.g., GitHub's 'Squash and merge' feature). Developers shared and refined these scripts in personal dotfiles, GitHub gists, and Stack Overflow answers, making it a widely adopted unofficial tool for Git cleanup.


title: PARAMETERS
content:
<b><i>&lt;submodule_path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the submodule's directory within the main repository. This path should match how the submodule was originally added or how it appears in your <i>.gitmodules</i> file.<br><br>


title: DESCRIPTION
content:
Removing a Git submodule manually involves a series of distinct steps: editing the <i>.gitmodules</i> file, removing the corresponding entry from the main repository's <i>.git/config</i>, ensuring the submodule's files are removed from the working directory and the Git index, and finally, committing these changes. This multi-step process can be cumbersome and prone to errors, potentially leaving behind orphaned files or inconsistent repository states.<br><br>The <b>git-delete-submodule</b> command automates this entire procedure, streamlining the removal of a submodule. It systematically updates the configuration files, removes the submodule's directory, and stages all necessary changes for commit. This command significantly simplifies submodule management, making the process less error-prone and more efficient for developers working with complex Git repositories.


title: CAVEATS
content:
<b>git-delete-submodule</b> is generally not a built-in Git command; it's commonly provided by external tools like <i>git-extras</i>. Therefore, its availability depends on whether such a utility package is installed on your system. Always verify its presence before attempting to use it. As this command makes permanent modifications to your repository's configuration and working directory, it is strongly advised to commit any outstanding changes or create a backup of your repository before execution to prevent unintended data loss or an unrecoverable state. While it cleans up references and the working directory, it typically does not prune the Git object database of the submodule's history; for that, further commands like <i>git gc --prune=now</i> might be necessary if disk space is a concern.


title: MANUAL DELETION PROCESS
content:
Before the advent of helpers like <b>git-delete-submodule</b>, users had to manually perform the following steps to remove a submodule:<br>1. Remove the submodule's entry from the <i>.gitmodules</i> file.<br>2. Remove the submodule's section from the <i>.git/config</i> file in the main repository.<br>3. Delete the submodule's directory from the working tree (e.g., using <i>rm -rf &lt;submodule_path&gt;</i>).<br>4. Unstage the submodule's directory from the index (e.g., <i>git rm --cached &lt;submodule_path&gt;</i>).<br>5. Stage and commit all these changes.<br><b>git-delete-submodule</b> automates these often intricate and sequential steps, significantly reducing the potential for error and improving efficiency.


title: HISTORY
content:
The <b>git-delete-submodule</b> command is not part of the core Git distribution. Its existence stems from the community's need for a more straightforward and automated way to manage submodule removal, a process that traditionally involves several manual steps across different Git commands and configuration files. It gained significant traction as a popular utility script, notably being included in community-driven projects like <i>git-extras</i>, which extends Git's capabilities with many useful, non-core functionalities. This command addresses a long-standing user experience challenge by simplifying a complex aspect of repository maintenance.


title: SYNOPSIS
content:
<b>Local deletion:</b><br><i>git tag -d &lt;tagname&gt; [...]</i><br><br><b>Remote deletion:</b><br><i>git push --delete &lt;remote&gt; &lt;tagname&gt; [...]</i>


title: PARAMETERS
content:
<b>-d, --delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>git tag</i> to delete the specified tag(s) from the local repository.<br><br><b>--delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>git push</i> to delete the specified ref(s) (in this case, tags) from the remote repository.<br><br><b>&lt;tagname&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the tag (or multiple tag names) to be deleted.<br><br><b>&lt;remote&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the remote repository (e.g., 'origin') from which to delete the tag. This is required for remote deletion.<br><br>


title: DESCRIPTION
content:
The concept of 'git-delete-tag' encompasses two primary operations in Git: deleting a tag from your <b>local repository</b> and deleting a tag from a <b>remote repository</b>.<br><br>To delete a tag locally, you use the <i>git tag -d</i> command. This removes the tag reference from your local Git repository. However, it's crucial to understand that deleting a local tag does <b>not</b> automatically remove it from any remote repositories it may have been pushed to.<br><br>To delete a tag from a remote repository (e.g., 'origin'), you must explicitly push a deletion command using <i>git push --delete</i>. This command tells the remote to remove the specified tag. Only after both local and remote deletions are performed will the tag be fully removed from your working environment and the shared repository.


title: CAVEATS
content:
Deleting a tag locally only removes its reference from your local repository; it does <b>not</b> remove it from any remote repositories it might have been pushed to. Similarly, deleting a tag from a remote does <b>not</b> remove it from other local repositories that have fetched it unless those repositories explicitly delete it themselves. Users with appropriate permissions can recreate a deleted tag if needed, potentially pointing to a different commit.


title: WHEN TO DELETE TAGS
content:
Tags are typically deleted when they were created by mistake (e.g., typo in tag name), are no longer relevant (e.g., an experimental tag), or need to be moved to a different commit (though this is less common for annotated tags that represent releases).


title: ANNOTATED VS. LIGHTWEIGHT TAGS
content:
While both types of tags can be deleted using these methods, annotated tags (created with <i>-a</i> or <i>-s</i>) are full Git objects that include a tagger name, email, date, and a message, similar to a commit. Lightweight tags are simply pointers to a specific commit. The deletion process is the same for both.


title: HISTORY
content:
Tagging has been a fundamental feature of Git since its inception, allowing users to mark significant points in history (like release versions). The ability to delete tags, both locally and remotely, was introduced to provide full lifecycle management for these references, allowing for correction or removal of erroneously created or obsolete tags.


title: SYNOPSIS
content:
<b>delta</b> [<i>OPTIONS</i>] [<i>FILE...</i>]<br><b>git diff</b> | <b>delta</b> [<i>OPTIONS</i>]<br><b>git log -p</b> | <b>delta</b> [<i>OPTIONS</i>]<br><b>diff -u</b> | <b>delta</b> [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b>--side-by-side</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display changes side-by-side for easier comparison of modified lines.<br><br><b>--line-numbers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show line numbers on the left and/or right side of the diff display.<br><br><b>--syntax-theme <THEME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply a specific syntax highlighting theme (e.g., `ansi`, `solarized-light`).<br><br><b>--paging <WHEN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when delta should use a pager: `auto` (default), `always`, or `never`.<br><br><b>--width <WIDTH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the screen width, useful for adjusting the layout of side-by-side views.<br><br><b>--minus-style <STYLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the styling for removed lines (e.g., `red reverse`).<br><br><b>--plus-style <STYLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the styling for added lines (e.g., `green bold`).<br><br><b>--file-style <STYLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the styling for file paths displayed in the diff header.<br><br><b>--hunk-header-style <STYLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the styling for hunk headers (e.g., `bold cyan`).<br><br><b>--word-diff-regex <REGEX></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable word-level diffing using a custom regular expression.<br><br><b>--diff-highlight</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply delta's built-in logic for highlighting modified words within lines.<br><br><b>--tabs <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the display width of tab characters.<br><br><b>--true-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force 24-bit true color output, if supported by the terminal emulator.<br><br><b>--navigate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable interactive navigation between hunks using keyboard shortcuts.<br><br><b>--config <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative configuration file instead of reading from `.gitconfig`.<br><br>


title: DESCRIPTION
content:
<i>git-delta</i> is a powerful command-line utility designed to enhance the readability of `git diff` output. It functions as a pager, taking standard diff input and rendering it with advanced features such as syntax highlighting, line numbers, and a choice of unified or side-by-side views. Key functionalities include intelligent word-diffing, highlighting of moved lines, improved hunk headers, and extensive customization options for colors, styles, and themes. By transforming raw diffs into a more intuitive and visually appealing format, <i>git-delta</i> significantly improves the experience of reviewing code changes, debugging, and understanding version control history. It aims to make diffs as clear and informative as possible, streamlining development workflows.


