Reputation: 6178
I have a repo that is about 24MB in size but the files in the project are actually just around 2MB. I was under the impression that a shallow clone with --depth 1 would pretty much get me down close to the 2MB of the actual files (sans entire repo).
When I do the shallow clone the new repo shows only the current branch but the size is identical (24MB) and looking at the repo with gitx I can see the entire history back to the initial commit.
I'd like a way to get just the current state of files (for uploading to a server) without all the history. Am I doing something wrong or just misunderstanding the purpose of the shallow clone?
Upvotes: 13
Views: 8582
Reputation: 332846
If this is a local clone, then the clone may be operating by hard linking objects in your new repository to those in your old repository (it does this as an optimization on local file systems). To see if this is the case, you can disable hard linking:
git clone --depth 1 --no-hardlinks /path/to/repo.git
If you're just trying to get the current state of files to upload to a server, you should use git archive
to generate a ZIP or tar archive of your tree.
Upvotes: 20
Reputation: 21397
I suggest it's because when doing a local clone, git ignores --depth
because it favours hardlinks. You can force the behaviour you expected with specifying the source repo with file:///home/user/path/to/repo
(i.e. with the file:/// prefix).
This is in the docs.
Upvotes: 4
Reputation: 1324557
As said in the comment, this is strange because generally not reproductible (see this thread).
Example of command that should work:
$ git clone --depth 1 git://github.com/rails/rails.git shallow
Initialized empty Git repository in /home/me/shallow/.git/
But anyway, on large repos, the gain achieved with a shallow clone seems not very impressive
Upvotes: 1
Reputation: 10106
git clone --depth 1 repo_url
should do what you want.
Maybe you put the options after repo url
? On some system they would be ignored.
Upvotes: 0