Summary: | dev-util/git installs many copies of identical file | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Viaken <Pflugerama> |
Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Fixed ebuild... |
Description
Viaken
2009-01-28 22:36:15 UTC
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. |