Hey, 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 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 https://groups.google.com/d/msg/git-users/-/yIC23MFPpNkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
