From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: "Alex Riesen" <raa.lkml@gmail.com>,
"Lukas Sandström" <lukass@etek.chalmers.se>,
git@vger.kernel.org, junkio@cox.net
Subject: Re: fix git-pack-redundant crashing sometimes
Date: Wed, 16 Nov 2005 12:13:42 -0800 [thread overview]
Message-ID: <7vlkzo73m1.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0511151552400.11232@g5.osdl.org> (Linus Torvalds's message of "Tue, 15 Nov 2005 15:58:02 -0800 (PST)")
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 15 Nov 2005, Alex Riesen wrote:
>>
>> Sorry, it doesn't. The code loops here:
>>
>> 401 /* find the permutations which contain all missing objects */
>> 402 perm_all = perm = get_all_permutations(non_unique);
>
> Looks like the whole thing is exponential.
This reminds me of one thing I have been meaning to remove.
The $GIT_OBJECT_DIRECTORY/info/pack file produced by
update-server-info records not just the packs (P lines), but its
dependencies (D lines) and top objects (T lines). If there are
more than one packs, D lines are meant to help the downloader to
figure out what other packs are needed to complete.
"meant to" is the keyword here. The original heuristics was
very bad (still correct but way suboptimal) and it has never
been updated. I do not use that information myself in http
fetch, and I do not think any Porcelain uses it.
Top objects are tags and commits in the pack that are not
reachable from any other object in the same pack. This can be
useful if you obtain just a packfile -- you can run server-info
to produce info/pack file, and resurrect the branch heads and
tags by using them --- you would not know what they are called,
though. I have been thinking it may be worthwhile to also
record bottom objects (B lines, naturally) --- tags and commits
in the pack that refer to tags or commits not present in the
same pack. This would help commit walkers to decide which pack
is more efficient to slurp when faced with multiple choices. If
you see a pack all whose bottom objects you have in your
repository, fetching that would complete the commit walking, so
the choice would become the matter of choosing such a pack among
multiple that has smallest number of objects you do not have
locally -- you would have the index file for each pack at that
point.
next prev parent reply other threads:[~2005-11-16 20:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-16 23:09 git-pack-redundant returns the most containing pack Alex Riesen
2005-11-16 23:23 ` Lukas Sandström
2005-11-15 15:49 ` fix git-pack-redundant crashing sometimes Alex Riesen
2005-11-15 16:08 ` Timo Hirvonen
2005-11-15 16:11 ` Alex Riesen
2005-11-15 17:28 ` Linus Torvalds
2005-11-15 21:38 ` Lukas Sandström
2005-11-15 21:24 ` [PATCH] Fix llist_sorted_difference_inplace in git-pack-redundant Lukas Sandström
2005-11-15 21:34 ` fix git-pack-redundant crashing sometimes Alex Riesen
2005-11-15 21:41 ` Lukas Sandström
2005-11-15 22:33 ` Alex Riesen
2005-11-15 23:13 ` Lukas Sandström
2005-11-16 7:01 ` Alex Riesen
2005-11-16 21:11 ` Alex Riesen
2005-11-15 23:58 ` Linus Torvalds
2005-11-16 20:13 ` Junio C Hamano [this message]
2005-11-16 21:37 ` Lukas Sandström
2005-11-16 23:59 ` Lukas Sandström
2005-11-17 16:56 ` Matthias Urlichs
2005-11-17 7:08 ` Fredrik Kuivinen
2005-11-17 13:11 ` [PATCH] Make git-pack-redundant non-horribly slow on large sets of packs Lukas Sandström
2005-11-17 20:39 ` Alex Riesen
2005-11-18 16:30 ` [PATCH] Fix bug introduced by the latest changes to git-pack-redundant Lukas Sandström
2005-11-18 21:53 ` [PATCH] Fix a bug in get_all_permutations Lukas Sandström
2005-11-17 7:45 ` git-pack-redundant returns the most containing pack Alex Riesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vlkzo73m1.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=lukass@etek.chalmers.se \
--cc=raa.lkml@gmail.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).