git-cp

Copy an existing file in a Git repo, staying in the same directory

$ git cp [file] [new_file]

$ git cp [path/to/file] [path/to/new_file]

Non-standard command; behavior depends on user implementation.

Typical alias/script usage:
git-cp SOURCE DESTINATION
git-cp [OPTIONS] SOURCE... DIRECTORY

SOURCE
    Path to the original file or directory to be copied.

DESTINATION
    Path where the copy should be created. Can be a new filename or a directory.

-f, --force
    Optional. If implemented, forces overwriting of existing destination files without prompting. This behavior typically relies on the underlying 'cp' command.

-r, -R, --recursive
    Optional. If implemented, copies directories and their contents recursively. This behavior typically relies on the underlying 'cp' command.

-v, --verbose
    Optional. If implemented, explains what is being done, typically by displaying the files being copied. This behavior typically relies on the underlying 'cp' command.

git-cp is not a standard, built-in command in Git.

Unlike git mv which provides a dedicated command for moving or renaming files while tracking their history, Git intentionally does not offer a direct git cp 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.

The functionality typically expected from a git-cp 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 cp command to duplicate the file, and then git add to add the newly created file to Git's staging area. Many users create custom aliases or scripts named git-cp to automate this two-step process for convenience. These custom implementations might vary widely in their exact options and behaviors.

The most significant caveat is that git-cp is not a built-in Git command. Its existence and behavior are entirely dependent on user or system administrator custom implementations (e.g., as a shell alias or script).

Therefore:
- It might not exist on your system.
- If it does exist, its exact functionality, supported options, and error handling can vary significantly.
- 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.
- 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.

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.

While git mv 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 git diff and git log then have algorithms to detect renames and copies by analyzing content similarity between commits.

This philosophy encourages users to use the standard operating system cp command for copying files, followed by git add for staging the new file, which aligns with Git's focus on managing the state of the working directory and index rather than directly manipulating historical relationships for copies at the command line.

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.

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 git blame or git log --follow), Git can intelligently detect a copy based on content similarity, but this is an analytical feature rather than a direct command-driven history link.

Because of this design, a standard git cp command was never included in the core Git distribution. The functionality for copying and staging is delegated to existing operating system tools (cp) combined with Git's staging mechanism (git add). Users who desire a single git cp command typically implement it themselves as a shell alias or a small wrapper script.

git-mv(1), git-add(1), git-rm(1), cp(1)