Why does “git clone” pack the object database when being passed a local file:/// url?

Question

The following describe the bash commands to be executed in order to reproduce the observed behavior. Although those have been run through msysgit, I suspect that the outcome should be similar on a *nix environment.

Setup the source repository

$ mkdir main && cd main
$ git init .
Initialized empty Git repository in d:/temp/main/.git/
$ echo a > a.txt
$ git add . && git commit -m "Initial commit"
[master (root-commit) e1ec355] Initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a.txt

Clone the source repository using a local file:/// url

$ cd ..
$ mkdir clonefromfileurl && cd clonefromfileurl
$ git clone file:///d:/temp/main
Cloning into 'main'...
remote: Counting objects: 3, done.
Receiving objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)

Clone the source repository using a local file path

$ cd ..
$ mkdir clonefrompath && cd clonefrompath
$ git clone /d:/temp/main
Cloning into 'main'...
done.

According to Wikipedia, a file url with a triple slash implies a local resource.

However, when cloning through a local file:/// url, the object database is packed before being transmitted (copied?). This is not the case when the location of the source repository is expressed as a local path.

Why does git behave in different ways considering that both the source and the target repo are hosted on localhost?

Answer 1

From git clone manual:

For local repositories, also supported by git natively, the following syntaxes may be used:

• /path/to/repo.git/
• file:///path/to/repo.git/

These two syntaxes are mostly equivalent, except the former implies --local option.

So when you are using file:///, it does not imply the --local clone, which you have to add explicitly.