0

I regularly want to get a few files from a large repository that has a huge number of tiny files and very frequent changes to parts of them.

Ideally I'd just fetch a shallow clone with -n and then check out just the directory containing the files I need. Curiously I just had a path that wasn't known (referenced in the history) after a git clone -n --depth=1 while it is evidently present on disc after a git clone --depth=1 (so without the -n option).

Looks like -depth is interpreted differently with or without that option present?

If I'm not doing anything else wrong, is there a way to deepen a shallow history until the latest commit to a given path - without first determining which commit that is (e.g. via the web interface)?

EDIT: here's what I've been doing:

> git clone -v --depth=1 -n github:macports/macports-ports mptree-git # github: expands to git@github.com:
Cloning into 'mptree-git'...
remote: Enumerating objects: 50097, done.
remote: Counting objects: 100% (50097/50097), done.
remote: Compressing objects: 100% (29444/29444), done.
remote: Total 50097 (delta 7644), reused 38087 (delta 6403), pack-reused 0
Receiving objects: 100% (50097/50097), 31.88 MiB | 5.31 MiB/s, done.
Resolving deltas: 100% (7644/7644), done.
> git -C mptree-git/ checkout security/KeePassXC
error: pathspec 'security/KeePassXC' did not match any file(s) known to git
Exit 1
RJVB
  • 698
  • 8
  • 18
  • If the file exists in the tip commit then the premise may be wrong- there's no deeper commit to find. Perhaps you can demonstrate how you are attempting to checkout just a folder and its output. Is it the case that you can find some files and not others after cloning without checkout? – TTT Aug 30 '23 at 12:16
  • 1
    There are alternatives to `git clone --depth=N ...`, namely `git clone --filter=blob:none ...` or `git clone --filter=tree:0 ...` that possibly fit your needs better. See https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ for more details. – hlovdal Aug 30 '23 at 12:39

1 Answers1

0

Turns out that git was apparently simply confused what to make of the pathspec I gave, and not a case of an inssuficiently deep history (= excluding the last commit to the desired path).

I knew I had found an answer once about checking out a single file/dir after cloning with -n so I spent some time and found this solution:

> git clone -v --depth=1 -n github:macports/macports-ports mptree-git
Cloning into 'mptree-git'...
remote: Enumerating objects: 50097, done.
remote: Counting objects: 100% (50097/50097), done.
remote: Compressing objects: 100% (29449/29449), done.
remote: Total 50097 (delta 7641), reused 38143 (delta 6398), pack-reused 0
Receiving objects: 100% (50097/50097), 31.88 MiB | 4.84 MiB/s, done.
Resolving deltas: 100% (7641/7641), done.
> git -C mptree-git checkout master -- security/KeePassXC
> ll mptree-git/security/KeePassXC/
total 14
2000237 1 drwxrwxr-x 3 bertin bertin    4 Sep  1 01:18 ./
2000236 1 drwxrwxr-x 3 bertin bertin    3 Sep  1 01:18 ../
2000239 9 drwxrwxr-x 2 bertin bertin    7 Sep  1 01:18 files/
2000238 5 -rwxrwxr-x 1 bertin bertin 6365 Sep  1 01:18 Portfile*

I'd still want to understand someday why it is that after a full clone -n there is no need to specify the branch (i.e. git checkout -- <path> will work).

RJVB
  • 698
  • 8
  • 18