When fetching from a local repo, it would be nice if git-fetch could use
hardlinks instead of copying files, just like git-clone does.  (I agree
that hardlinking a huge pack to avoid copying a few blobs may be
debatable, but having the option to do so nonetheless would be nice.)

tags 573909 + upstream
thanks

Frédéric Brière wrote:
/usr/share/doc/git-core/contrib/workdir/git-new-workdir?

I think it is very useful precisely because it avoids the fetch step
completely.  Sometimes I am working on multiple patches at a time,
with separate work trees to speed up 'make' by avoiding needless
branch switching.  I am only happy to forgo the flexibility I could
get from explicitly synchronizing the object dbs and refs.

On topic, this sounds like a reasonable request, if a little weird. :)

'git clone -s' might be a workaround as long as you are aware of the
dangers of gc-ing in the parent repository.

Cool!  I didn't know Git was okay with using symlinks like that.

My need was to merge three (big) repos into a single tree to replace
them all.  I don't think info/alternates would have been a viable
option, since I wanted to get rid of the other ones.  (I guess I
could've repacked without --local right after, but repacking gigs of
data on an old Athlon is a b*tch.)

Frédéric Brière wrote:

Thanks for the explanation.  Sounds compelling to me.  (The best workaround
I can imagine is to hardlink the packs by hand.)

Maybe ‘fetch-pack --all’ could learn a --local option to imitate
clone --local, and ‘fetch --local’ would run ‘fetch-pack --local --all’ no
matter what refs it was asked to fetch.  That would avoid questions about
which packs to grab.