I would reopen http://bugs.gentoo.org/170066 if I could, because it's the same issue and has the same fix, but it is still an issue in dev-util/git-1.6.1. Patch: --- /usr/portage/dev-util/git/git-1.6.1.1.ebuild 2009-01-26 07:16:53.000000000 -0500 +++ /usr/local/portage/dev-util/git/git-1.6.1.1.ebuild 2009-01-28 17:27:54.000000000 -0500 @@ -106,2 +106,3 @@ -e "s:^\(AR = \).*$:\1$(tc-getAR):" \ + -e "s:ln :ln -s :g" \ Makefile || die "sed failed" I'll upload it seperately, too, but it's a simple fix...
Created attachment 180025 [details] Fixed ebuild...
Obviously, you failed to understand that bug. Hardlinks don't waste space, as they are simply additional references to a file. If you checked 'du' on those files, you'd see there's only one file actually using space. Check 'man du' on hardlinks. In example, compare output of 'du /usr/libexec/git-core/git-commit /usr/libexec/git-core/git-commit-tree' to 'du -l /usr/libexec/git-core/git-commit /usr/libexec/git-core/git-commit-tree'
And just for reference with dev-util/git-1.6.0.6: find /usr/libexec/git-core/ -print0 |du -hs --files0-from=- 4,9M /usr/libexec/git-core/ 4,0K /usr/libexec/git-core/git-quiltimport 28K /usr/libexec/git-core/git-send-email 12K /usr/libexec/git-core/git-bisect 4,0K /usr/libexec/git-core/git-merge-one-file 12K /usr/libexec/git-core/git-filter-branch 28K /usr/libexec/git-core/git-cvsimport 4,0K /usr/libexec/git-core/git-sh-setup 40K /usr/libexec/git-core/git-archimport 16K /usr/libexec/git-core/git-am 12K /usr/libexec/git-core/git-rebase 4,0K /usr/libexec/git-core/git-request-pull 160K /usr/libexec/git-core/git-mktag 4,0K /usr/libexec/git-core/git-merge-resolve 8,0K /usr/libexec/git-core/git-relink 160K /usr/libexec/git-core/git-mktree 168K /usr/libexec/git-core/git-imap-send 160K /usr/libexec/git-core/git-hash-object 200K /usr/libexec/git-core/git-fast-import 8,0K /usr/libexec/git-core/git-parse-remote 16K /usr/libexec/git-core/git-rebase--interactive 160K /usr/libexec/git-core/git-show-index 12K /usr/libexec/git-core/git-cvsexportcommit 24K /usr/libexec/git-core/git-add--interactive 4,0K /usr/libexec/git-core/git-lost-found 4,0K /usr/libexec/git-core/git-merge-octopus 4,0K /usr/libexec/git-core/git-repack 8,0K /usr/libexec/git-core/git-pull 184K /usr/libexec/git-core/git-merge-tree 168K /usr/libexec/git-core/git-daemon 156K /usr/libexec/git-core/git-patch-id 160K /usr/libexec/git-core/git-update-server-info 148K /usr/libexec/git-core/git-svn 184K /usr/libexec/git-core/git-instaweb 4,0K /usr/libexec/git-core/git-web--browse 156K /usr/libexec/git-core/git-var 16K /usr/libexec/git-core/git-submodule 164K /usr/libexec/git-core/git-pack-redundant 12K /usr/libexec/git-core/git-mergetool 320K /usr/libexec/git-core/git-http-push 176K /usr/libexec/git-core/git-index-pack 164K /usr/libexec/git-core/git-unpack-file 156K /usr/libexec/git-core/git-merge-index 8,0K /usr/libexec/git-core/git-stash
(In reply to comment #2) > Obviously, you failed to understand that bug. > > Hardlinks don't waste space, as they are simply additional references > to a file. If you checked 'du' on those files, you'd see there's > only one file actually using space. Check 'man du' on hardlinks. > > In example, compare output of > 'du /usr/libexec/git-core/git-commit /usr/libexec/git-core/git-commit-tree' > to > 'du -l /usr/libexec/git-core/git-commit /usr/libexec/git-core/git-commit-tree' > I didn't fail to understand the bug. I know what hard links are. Based on what I read in the bug, portage doesn't support them? Now, it's possible that qsize was lying to me, but before I made that change, it showed git using nearly 80MB of disk space, whereas after it showed 9MB.
Perhaps qsize doesn't handle hardlinks correctly ? Actually, it seems that neither does 'equery s'. But that would be a bug in portage-utils/gentoolkit, not in git.
And somewhere in that bug it's written it was fixed in one of the portage 2.1.6 rc.
I see. Well, I apologize for the confusion. I was under the impression the the ebuild was changed, and somehow it hadn't propogated to the newer ones. Thanks for clearing that up for me.
