good point, could have mentioned that earlier. We are using ssh (not dumb 
http). Even a local clone created without specifying the file: protocol and 
with --no-hardlinks results in a big repo copy locally: 

git clone --depth 1 --no-hardlinks main -b subtrees/xyz xyz

If I clone with 

git clone --depth 1 --no-hardlinks* file://*path/to/main -b subtrees/xyz 

I end up with a small local clone though (actually --no-hardlinks doesn't 
matter in this case of course... the import thing is file:)

Remotely I always get a big one, no matter what I do... (also tried the 
native git protocol already, but by default we are planning to use ssh).

Any other ideas?

Am Donnerstag, 30. August 2012 14:01:27 UTC+2 schrieb Antony Male:
> On Thursday, 30 August 2012 11:34:52 UTC+1, Haasip Satang wrote:
>> So the question actually is why does
>> git clone --depth 1 --no-hardlinks *file:///*home/me/gitTests/subtreeRepo 
>> -b subtrees/xyz *xyz *
>> give me a small clone (*but only locally), *while cloning from remote I 
>> get a big one.
> What transport are you cloning over?
> When cloning over a "smart" transport (smart http(s), ssh, git://) a git 
> process on the local machine communicates with one on the remote machine, 
> and between them they negotiate which objects need to be transferred. The 
> remote process then compresses these objects into a custom packfile, and 
> this is transferred.
> When cloning over a "dumb" protocol (dumb http(s), ftp), there's no way of 
> spawning a git process on the remote machine. Therefore the local process 
> just has to download whatever packfiles are available. If there are no 
> packfiles corresponding to the objects required for a shallow clone, git 
> may (in the worst case) end up downloading the entirety of your history, 
> even if it doesn't need to. The same goes for fetches: if the only way to 
> get the required new objects is to download everything, this is what git 
> has to do.
> I suspect you're cloning over a dumb transport, and this is what's causing 
> the effects you're seeing. Smart http(s) has been supported by git for a 
> long time, and, although trickier to set up on the remote side, is 
> definitely worth it.
> Hope that helps,
> Antony 

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to