Nicolas Pitre [off-list ref] writes:
It appears that the git installation serving clone requests for
git://gcc.gnu.org/git/gcc.git generates lots of unreferenced objects. I
just cloned it and the pack I was sent contains 1383356 objects (can be
determined with 'git show-index < .git/objects/pack/*.idx | wc -l').
However, there are only 978501 actually referenced objects in that
cloned repository ( 'git rev-list --all --objects | wc -l'). That makes
for 404855 useless objects in the cloned repository.
Those objects are not useless. They are referenced by the remote refs
on the remote side, which are not fetched by default. If you clone a
mirror of the repository you'll see no unreferenced objects.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sat, Aug 8, 2009 at 2:11 AM, Andreas Schwab[off-list ref] wrote:
Nicolas Pitre [off-list ref] writes:
quoted
It appears that the git installation serving clone requests for
git://gcc.gnu.org/git/gcc.git generates lots of unreferenced objects. I
just cloned it and the pack I was sent contains 1383356 objects (can be
determined with 'git show-index < .git/objects/pack/*.idx | wc -l').
However, there are only 978501 actually referenced objects in that
cloned repository ( 'git rev-list --all --objects | wc -l'). That makes
for 404855 useless objects in the cloned repository.
Those objects are not useless. They are referenced by the remote refs
on the remote side, which are not fetched by default. If you clone a
mirror of the repository you'll see no unreferenced objects.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Thanks... It is a difference between svn and git mentality probably -
one only pushes reasonably reliable code to a public git repository,
whereas anything transient is recorded in svn - I think many of the
unreferenced objects are svn user-branches (which are probably of use
to people who intend to work on gcc for fairly extended periods,
rather than casual users like me).
The case with gcc is probably quite extreme - many user branches, and
very large code base - but is there anything on the git side with git
gc which can lessen this kind of pathological behavior (expanding
packs)?
Thanks a lot for the explanation and the discussion.
Hin-Tak
On Sat, 8 Aug 2009, Andreas Schwab wrote:
Nicolas Pitre [off-list ref] writes:
quoted
It appears that the git installation serving clone requests for
git://gcc.gnu.org/git/gcc.git generates lots of unreferenced objects. I
just cloned it and the pack I was sent contains 1383356 objects (can be
determined with 'git show-index < .git/objects/pack/*.idx | wc -l').
However, there are only 978501 actually referenced objects in that
cloned repository ( 'git rev-list --all --objects | wc -l'). That makes
for 404855 useless objects in the cloned repository.
Those objects are not useless. They are referenced by the remote refs
on the remote side, which are not fetched by default. If you clone a
mirror of the repository you'll see no unreferenced objects.
If you do a clone using the git:// protocol and the server sends you
only the ref for the trunk branch, then it should send you only objects
reachable from that branch. Any extra objects sent by the server are
useless to me and wastes my and everyone else's bandwidth, and on my
next repack those objects are pruned anyway. The point of the git
protocol is _not_ necessarily to send a copy of the remote pack file
over, even during a clone.
Nicolas