Debian Bug report logs - #573909
git-core: Have git-fetch use hardlinks on local copies

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Frédéric Brière <fbriere@fbriere.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: git-core: Have git-fetch use hardlinks on local copies

Date: Sun, 14 Mar 2010 18:10:16 -0400

Package: git-core
Version: 1:1.7.0-1
Severity: wishlist

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.)


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.29.6 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages git-core depends on:
ii  libc6                   2.10.2-6         Embedded GNU C Library: Shared lib
ii  libcurl3-gnutls         7.20.0-1         Multi-protocol file transfer libra
ii  libdigest-sha1-perl     2.12-1           NIST SHA-1 message digest algorith
ii  liberror-perl           0.17-1           Perl module for error/exception ha
ii  libexpat1               2.0.1-7          XML parsing C library - runtime li
ii  perl-modules            5.10.1-11        Core Perl modules
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages git-core recommends:
ii  less                          436-1      pager program similar to more
ii  openssh-client [ssh-client]   1:5.3p1-3  secure shell (SSH) client, for sec
ii  patch                         2.6-2      Apply a diff file to an original
ii  rsync                         3.0.7-2    fast remote file copy program (lik

Versions of packages git-core suggests:
pn  git-arch                      <none>     (no description available)
ii  git-cvs                       1:1.7.0-1  fast, scalable, distributed revisi
pn  git-daemon-run                <none>     (no description available)
pn  git-doc                       <none>     (no description available)
ii  git-email                     1:1.7.0-1  fast, scalable, distributed revisi
pn  git-gui                       <none>     (no description available)
ii  git-svn                       1:1.7.0-1  fast, scalable, distributed revisi
ii  gitk                          1:1.7.0-1  fast, scalable, distributed revisi
pn  gitweb                        <none>     (no description available)

-- no debconf information

Message #10 received at 573909@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Frédéric Brière <fbriere@fbriere.net>, control@bugs.debian.org

Cc: 573909@bugs.debian.org

Subject: Re: Bug#573909: git-core: Have git-fetch use hardlinks on local copies

Date: Sun, 14 Mar 2010 18:14:01 -0500

tags 573909 + upstream
thanks

Frédéric Brière wrote:

> 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.

Off topic: are you aware of
/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.

> (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.)

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.

Message #17 received at 573909@bugs.debian.org (full text, mbox, reply):

From: Frédéric Brière <fbriere@fbriere.net>

To: Jonathan Nieder <jrnieder@gmail.com>, 573909@bugs.debian.org

Subject: Re: Bug#573909: git-core: Have git-fetch use hardlinks on local copies

Date: Sun, 14 Mar 2010 19:31:00 -0400

On Sun, Mar 14, 2010 at 06:14:01PM -0500, Jonathan Nieder wrote:
> Off topic: are you aware of
> /usr/share/doc/git-core/contrib/workdir/git-new-workdir?

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

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

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.)


-- 
Q: What's the big deal about rm, I have been deleting stuff for years?  And
   never lost anything.. oops!
A: ...
		-- From the Frequently Unasked Questions

Message #22 received at 573909@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Frédéric Brière <fbriere@fbriere.net>

Cc: 573909@bugs.debian.org

Subject: Re: Bug#573909: git-core: Have git-fetch use hardlinks on local copies

Date: Sun, 14 Mar 2010 19:18:02 -0500

Frédéric Brière wrote:

> 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.)

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.

Send a report that this bug log contains spam.