git clone, "checking out files" phase skipped
ubuntu@site3-user03:/projects$ git clone git://git.alsa-project.org/alsa-driver.git
was carried out. It resulted in following output
Cloning into 'alsa-driver'...
remote: Counting objects: 208801, done.
remote: Compressing objects: 100% (41538/41538), done.
remote: Total 208801 (delta 162528), reused 206283 (delta 160012)
Receiving objects: 100% (208801/208801), 37.00 MiB | 1.53 MiB/s, done.
Resolving deltas: 100% (162528/162528), done.
Checking connectivity... done.
ubuntu@site3-user03:/projects$
However, for some unknown reason the clone process did not include the stage Checking out files: 100% (xyz/zyx), done.
Usually the clone process includes checkout to working space. In end-effect my private fork has empty working space and myself has to decide where to branch out which might not be straightforward.
ubuntu@site3-user03:/projects/alsa-driver$ git ls-remote origin
a1c6fbc1a65d8a755425d0b56077868148512891 HEAD
1721fb542b00f1c7aebc923732068f403b6062ad refs/heads/build
a1c6fbc1a65d8a755425d0b56077868148512891 refs/heads/master
71b3b2b41dfbdeda78e2e7b62fe2afa8b451fb6e refs/heads/mirror
b044dfe04f636d87fd391b575ba41e495e68e973 refs/heads/release
6386d9e39e6f364698648f4e4741897f83b00121 refs/tags/build/v1.0.1
234b00ebe6e1513c3ce8cdd83999c255bd5516eb refs/tags/build/v1.0.10
f888eb06d4c7af89faa2f9dda189d488312ecb07 refs/tags/build/v1.0.10rc1
e4c4d1037521f536b79f8d145979ec869db353f9 refs/tags/build/v1.0.10rc2
....
many more tags
My expectation is the clone carries out the check-out based on remote's HEAD which points to certain commit on remote.
What is the possible reason of the check-out stage had been skipped?
During the clone process was in progress I created small readme file in the working space. However that file stays untracked up to this moment. There is no plan to track that file.
Can this file creation have disturbed clone process so it could not include check-out stage?
ubuntu@site3-user03:/projects$ git clone git@git.alsa-project.org:alsa-driver.git alsa-driver
Cloning into 'alsa-driver'...
The authenticity of host 'git.alsa-project.org (77.48.224.243)' can't be established.
RSA key fingerprint is f1:0e:a7:1f:bc:1b:9f:71:00:85:c9:4a:8a:d9:d6:33.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
ubuntu@site3-user03:/projects$
So, I aborted it because am used to have straightforward clone process, furthermore not the slightest idea about all resulting effects on confirming to continue on unauthenticated host.
git help clone
and the examples made there use among others following URL format
The following syntaxes may be used with them:
· git://host.xz[:port]/path/to/repo.git/
· http[s]://host.xz[:port]/path/to/repo.git/
...
git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
git clone --reference /git/linux.git
git://git.kernel.org/pub/scm/.../linux.git
my-linux
· Create a bare repository to publish your changes to the public:
git clone --bare -l /home/proj/.git /pub/scm/proj.git
As for used setup following applies as well:
ubuntu@site3-user03:/$ sudo find / -type f -name known_hosts
[sudo] password for ubuntu:
ubuntu@site3-user03:/$
One time in the past I have had similar effect with other clone. That time it was clone of Linux kernel public repo for MSM SoC. However, that time the clone process generated also some message of the kind "unable to clone because no ??? found on remote". Forgotten what ??? read. So in the end-effect I had also to do check-out manually subsequently to clone process. However, such warning did not come in this case, forking alsa-driver public repo.
I've never seen using the URL format you use to clone a repository, since the standard should be : git://git.alsa-project.org:alsa-driver.git , with the format you used you are cloning the repository in bare mode, that is like specifying the --bare command line option, that basically perform :
Make a bare Git repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git , make the <directory> itself the $GIT_DIR . This obviously implies the -n because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/ . When this option is used, neither remote-tracking branches nor the related configuration variables are created.
If you take a look at the documentation of the project that you are trying to clone you'll notice that to clone that specific project you have to :
git clone git@git.alsa-project.org:alsa-driver.git alsa-driver
cd alsa-driver
git branch build remotes/origin/build
git branch mirror remotes/origin/mirror
git branch release remotes/origin/release