Does git clone copy all source code?

Question

Does git clone create a copy of every single source file/version on your local machine, for all branches?

Or does it just copy master, and all of the branches are just references? (and when you checkout a branch it downloads commits for that branch?)

Basically I'm wondering if I have the source from 100 different branches on my machine when i really only want a small handful.

Thanks.

Answer 1

It does get the full history of the remote repository.

What it doesn't get is the config and the hooks (they are not clone, pulled or pushed).

It also doesn't create a local branch for each of the remote branches cloned.
That is why if you are cloning your clone (two clones in a row), you will end up with only one branch.
As mentioned in git clone

• Clones a repository into a newly created directory,
• creates remote-tracking branches for each branch in the cloned repository (visible using git branch -r), and
• creates and checks out an initial branch that is forked from the cloned repository's currently active branch.

---

Note that with Git 2.44 (Q1 2024), "git clone"^(man) has been prepared to allow cloning a repository with a non-default hash function into a repository that uses the reftable backend.

As a result, its inner-working evolves: "git clone" now spawns "git-remote-curl" to fetch the refs from the remote, which in turn needs to re-discover the repository in case it was not yet initialized.

See commit 18c9cb7, commit 3c8f60c, commit 360822a, commit 9159029, commit bab2283, commit 56cd033, commit 79543e7 (12 Dec 2023) by Patrick Steinhardt (pks-t).
^{(Merged by Junio C Hamano -- gitster -- in commit 94e8e40, 27 Dec 2023)}

remote-curl: rediscover repository when fetching refs

^{Signed-off-by: Patrick Steinhardt}

The reftable format encodes the hash function used by the repository inside of its tables.
The reftable backend thus needs to be initialized with the correct hash function right from the start, or otherwise we may end up writing tables with the wrong hash function.
But git-clone(1) initializes the reference database before learning about the hash function used by the remote repository, which has never been a problem with the reffiles backend.

To fix this, we will have to change git-clone(1) to be more careful and only create the reference backend once it learned about the remote hash function.
That creates a problem for git-remote-curl(1), which will then be spawned at a time where the repository is not yet fully-initialized.
Consequentially, git-remote-curl(1) will fail to detect the repository, which eventually causes it to error out once it is asked to fetch remote objects.

We can address this issue by trying to re-discover the Git repository in case none was detected at startup time.
With this change, the clone will look as following:

1. git-clone(1) sets up the initial repository, excluding the reference database.
2. git-clone(1) spawns git-remote-curl(1), which will be unable to detect the repository due to a missing "HEAD".
3. git-clone(1) asks git-remote-curl(1) to list remote references.
   That works just fine as this step does not require a local repository
4. git-clone(1) creates the reference database as it has now learned about the hash function.
5. git-clone(1) asks git-remote-curl(1) to fetch the remote packfile.
   The latter notices that it does not have a repository available, but it now knows to try and re-discover it.

If the re-discovery succeeds in the last step we can continue with the clone.

---

A custom remote helper no longer cannot access the newly created repository during "git clone"^(man), which is a regression in Git 2.44.
This has been corrected with Git 2.45 (Q2 2024), batch 5.

See commit 199f44c (27 Feb 2024) by Patrick Steinhardt (pks-t).
^{(Merged by Junio C Hamano -- gitster -- in commit ce65a18, 07 Mar 2024)}

builtin/clone: allow remote helpers to detect repo

^{Reported-by: Mike Hommey
Signed-off-by: Patrick Steinhardt}

In 18c9cb7 ("builtin/clone: create the refdb with the correct object format", 2023-12-12, Git v2.44.0-rc0 -- merge listed in batch #4), we have changed git-clone(1) so that it delays creation of the refdb until after it has learned about the remote's object format.
This change was required for the reftable backend, which encodes the object format into the tables.
So if we pre-initialized the refdb with the default object format, but the remote uses a different object format than that, then the resulting tables would have encoded the wrong object format.

This change unfortunately breaks remote helpers which try to access the repository that is about to be created.
Because the refdb has not yet been initialized at the point where we spawn the remote helper, we also don't yet have "HEAD" or "refs/".
Consequently, any Git commands ran by the remote helper which try to access the repository would fail because it cannot be discovered.

This is essentially a chicken-and-egg problem: we cannot initialize the refdb because we don't know about the object format.
But we cannot learn about the object format because the remote helper may be unable to access the partially-initialized repository.

Ideally, we would address this issue via capabilities.
But the remote helper protocol is not structured in a way that guarantees that the capability announcement happens before the remote helper tries to access the repository.

Instead, fix this issue by partially initializing the refdb up to the point where it becomes discoverable by Git commands.

Answer 2

Short answer is that after the clone, you have all the files from the master branch, but have the full repository locally. This means you do not have to network access to checkout a different branch.