From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Philip Oakley <philipoakley@iee.org>,
git@vger.kernel.org
Subject: Re: [PATCH v3 00/14] Clean up how fetch_pack() handles the heads list
Date: Mon, 17 Sep 2012 14:55:37 +0200 [thread overview]
Message-ID: <50571DC9.2030602@alum.mit.edu> (raw)
In-Reply-To: <7vhar5leal.fsf@alter.siamese.dyndns.org>
On 09/11/2012 12:10 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>>> OK. As long as the sort order matches the order string-list
>>> internally uses for its bisection search, it won't be a problem,
>>> then.
>>
>> The sorting is crucial but there is no bisection involved. The sorted
>> linked-list of references available from the remote and the sorted
>> string_list of requested references are iterated through in parallel.
>
> What I meant was that the order used by string-list is pretty much
> internal to string-list implementation for its "quickly locate where
> to insert" bisection. It happens to be the byte value order, I
> think, but the point is whatever order it is, that has to match the
> order we keep references in the other data source you walk in
> parallel to match (i.e. the linked list of references).
Yes, your point is good that the two sort orders have to agree.
Currently, they both use strcmp() order, so the situation is OK.
It is interesting that you consider the sort order of string_list to be
somewhat of an internal implementation detail. I had thought of its
current behavior as being the obvious thing and considered it part of
the API's contract. For example, the current sort order is already
observable via the API through iteration or by calling
print_string_list(). Therefore I think that we should document the
strcmp() sort order as part of the string_list contract. Patch coming soon.
If, at some future time, somebody wants a string_list that is sorted by
a different criterion, then the order should be determined via a
callback function specified by the user. The callback function could
even be stored in the string_list header, to allow such lists to be used
in combination with the "functions for sorted lists only".
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2012-09-17 12:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-09 6:19 [PATCH v3 00/14] Clean up how fetch_pack() handles the heads list Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 01/14] t5500: add tests of error output for missing refs Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 02/14] t5500: add tests of fetch-pack --all --depth=N $URL $REF Michael Haggerty
2012-09-10 20:46 ` Junio C Hamano
2012-09-10 21:53 ` Michael Haggerty
2012-09-18 23:37 ` Philip Oakley
2012-09-09 6:19 ` [PATCH v3 03/14] Rename static function fetch_pack() to http_fetch_pack() Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 04/14] fetch_pack(): reindent function decl and defn Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 05/14] Change fetch_pack() and friends to take string_list arguments Michael Haggerty
2012-09-10 20:56 ` Junio C Hamano
2012-09-17 12:24 ` Michael Haggerty
2012-09-17 22:10 ` Junio C Hamano
2012-09-17 22:17 ` Jeff King
2012-09-18 20:49 ` Junio C Hamano
2012-09-09 6:19 ` [PATCH v3 06/14] filter_refs(): do not check the same sought_pos twice Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 07/14] fetch_pack(): update sought->nr to reflect number of unique entries Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 08/14] filter_refs(): delete matched refs from sought list Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 09/14] filter_refs(): build refs list as we go Michael Haggerty
2012-09-10 21:18 ` Junio C Hamano
2012-09-09 6:19 ` [PATCH v3 10/14] filter_refs(): simplify logic Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 11/14] cmd_fetch_pack(): return early if finish_connect() fails Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 12/14] fetch-pack: report missing refs even if no existing refs were received Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 13/14] cmd_fetch_pack(): simplify computation of return value Michael Haggerty
2012-09-09 6:19 ` [PATCH v3 14/14] fetch-pack: eliminate spurious error messages Michael Haggerty
2012-09-09 10:20 ` [PATCH v3 00/14] Clean up how fetch_pack() handles the heads list Junio C Hamano
2012-09-09 13:05 ` Jeff King
2012-09-09 18:15 ` Junio C Hamano
2012-09-10 21:59 ` Michael Haggerty
2012-09-10 22:10 ` Junio C Hamano
2012-09-17 12:55 ` Michael Haggerty [this message]
2012-09-17 20:39 ` Junio C Hamano
2012-09-10 21:21 ` Junio C Hamano
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=50571DC9.2030602@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=philipoakley@iee.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).