From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Drew Northup <drew.northup@maine.edu>,
Jakub Narebski <jnareb@gmail.com>,
Heiko Voigt <hvoigt@hvoigt.net>,
Johan Herland <johan@herland.net>,
Julian Phillips <julian@quantumfyre.co.uk>
Subject: Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
Date: Tue, 13 Dec 2011 23:13:06 +0100 [thread overview]
Message-ID: <4EE7CDF2.3040408@alum.mit.edu> (raw)
In-Reply-To: <4EE7A387.3070400@alum.mit.edu>
On 12/13/2011 08:12 PM, Michael Haggerty wrote:
> On 12/13/2011 07:37 AM, Junio C Hamano wrote:
>> Another possibility is to keep the extra_ref interface in refs.c, without
>> any of your changes (i.e. keep it just as a flat list, with the original
>> interface to append to it without any dedup and other fancy features) and
>> also keep the special casing of it in for_each_ref(). AFAIK, that is the
>> only iterator that should care about the extra refs. Thinking about it a
>> bit more, removal of add_extra_ref() API may be unnecessarily complex with
>> no real gain. For example, extra refs added in builtin/clone.c is used by
>> builtin/fetch-pack.c, meaning that the codepath that discovers and
>> remembers these extra history anchor points and the codepath that uses
>> them while walking the history are not localized and we would need some
>> sort of "extra ref API" anyway. I am leaning towards this option.
>
> In a few minutes I will post a series of patches that store extra_refs
> in a linked list separate from the reference caches, and iterates over
> them only from for_each_ref(). I could rebase my ref-api-D changes on
> top of this patch series in such a way that the extra refs are kept in
> non-hierarchical storage. But I leave for vacation on Thursday so it is
> quite likely that I won't be able to get it finished before I return in
> the new year.
I forgot to mention that I think it would be better to separate the
handling of extra refs even more than do the patches
[PATCH 0/6] Handle extra_refs separately from ref_caches
Namely, we should figure out what code wants to set extra refs and or
wants to include extra refs in its iteration over references. The
setters don't have to be changed, but the readers should be. After the
above patch series, the readers call for_each_ref(), which always calls
do_for_each_extra_ref(). The call to do_for_each_extra_ref() should be
taken out of for_each_ref() and called directly by any readers who want
to support extra_refs. Other readers should only call for_each_ref().
(do_for_each_extra_ref(), probably under a different name, would have to
become public.) That way, for_each_ref() could ignore the extra refs
entirely, and other callers of for_each_ref() wouldn't risk getting
extra refs by accident.
Today I spent some time trying to figure out what callers of
for_each_ref() could possible want to deal with extra refs, but I got
lost in the deep call trees and undocumented function declarations. At
the top it is pretty clear that all such code paths start in cmd_clone()
or cmd_receive_pack(). But there are so many calls to the
for_each_ref*() family of functions that I wasn't able to determine
exactly which should allow for extra refs and which shouldn't. (I even
wonder whether extra refs might be used inadvertently in some places
where they aren't wanted, for example in one of the myriad calls to
setup_revisions().) If somebody could put his finger on the
for_each_ref() callers who want to support extra refs, that would be
very helpful.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2011-12-13 22:13 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 5:38 [PATCH v2 00/51] ref-api-C and ref-api-D re-roll mhagger
2011-12-12 5:38 ` [PATCH v2 01/51] struct ref_entry: document name member mhagger
2011-12-12 5:38 ` [PATCH v2 02/51] refs: rename "refname" variables mhagger
2011-12-13 0:37 ` Junio C Hamano
2011-12-12 5:38 ` [PATCH v2 03/51] refs: rename parameters result -> sha1 mhagger
2011-12-12 5:38 ` [PATCH v2 04/51] clear_ref_array(): rename from free_ref_array() mhagger
2011-12-12 5:38 ` [PATCH v2 05/51] is_refname_available(): remove the "quiet" argument mhagger
2011-12-12 5:38 ` [PATCH v2 06/51] parse_ref_line(): add docstring mhagger
2011-12-12 5:38 ` [PATCH v2 07/51] add_ref(): " mhagger
2011-12-12 5:38 ` [PATCH v2 08/51] is_dup_ref(): extract function from sort_ref_array() mhagger
2011-12-12 8:33 ` Jeff King
2011-12-12 11:44 ` Michael Haggerty
2011-12-12 17:14 ` Junio C Hamano
2011-12-12 22:33 ` Junio C Hamano
2011-12-13 4:35 ` Michael Haggerty
2011-12-13 5:00 ` Michael Haggerty
2011-12-12 5:38 ` [PATCH v2 09/51] refs: change signatures of get_packed_refs() and get_loose_refs() mhagger
2011-12-12 5:38 ` [PATCH v2 10/51] get_ref_dir(): change signature mhagger
2011-12-12 5:38 ` [PATCH v2 11/51] resolve_gitlink_ref(): improve docstring mhagger
2011-12-12 5:38 ` [PATCH v2 12/51] Pass a (ref_cache *) to the resolve_gitlink_*() helper functions mhagger
2011-12-12 5:38 ` [PATCH v2 13/51] resolve_gitlink_ref_recursive(): change to work with struct ref_cache mhagger
2011-12-12 5:38 ` [PATCH v2 14/51] repack_without_ref(): remove temporary mhagger
2011-12-12 5:38 ` [PATCH v2 15/51] create_ref_entry(): extract function from add_ref() mhagger
2011-12-12 5:38 ` [PATCH v2 16/51] add_ref(): take a (struct ref_entry *) parameter mhagger
2011-12-12 5:38 ` [PATCH v2 17/51] do_for_each_ref(): correctly terminate while processesing extra_refs mhagger
2011-12-12 22:41 ` Junio C Hamano
2011-12-12 5:38 ` [PATCH v2 18/51] do_for_each_ref_in_array(): new function mhagger
2011-12-12 5:38 ` [PATCH v2 19/51] do_for_each_ref_in_arrays(): " mhagger
2011-12-12 5:38 ` [PATCH v2 20/51] repack_without_ref(): reimplement using do_for_each_ref_in_array() mhagger
2011-12-12 22:44 ` Junio C Hamano
2011-12-12 5:38 ` [PATCH v2 21/51] names_conflict(): new function, extracted from is_refname_available() mhagger
2011-12-12 5:38 ` [PATCH v2 22/51] names_conflict(): simplify implementation mhagger
2011-12-12 5:38 ` [PATCH v2 23/51] is_refname_available(): reimplement using do_for_each_ref_in_array() mhagger
2011-12-12 5:38 ` [PATCH v2 24/51] refs.c: reorder definitions more logically mhagger
2011-12-12 5:38 ` [PATCH v2 25/51] free_ref_entry(): new function mhagger
2011-12-12 5:38 ` [PATCH v2 26/51] check_refname_component(): return 0 for zero-length components mhagger
2011-12-12 5:38 ` [PATCH v2 27/51] struct ref_entry: nest the value part in a union mhagger
2011-12-12 5:38 ` [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir mhagger
2011-12-13 0:45 ` Junio C Hamano
2011-12-13 5:43 ` Michael Haggerty
2011-12-13 6:37 ` Junio C Hamano
2011-12-13 19:12 ` Michael Haggerty
2011-12-13 19:17 ` Junio C Hamano
2011-12-13 22:13 ` Michael Haggerty [this message]
2011-12-13 23:24 ` Junio C Hamano
2011-12-14 0:19 ` Junio C Hamano
2011-12-14 2:33 ` Jeff King
2011-12-15 8:19 ` Michael Haggerty
2011-12-15 8:37 ` Jeff King
2012-01-17 15:07 ` Michael Haggerty
2012-02-10 14:51 ` Michael Haggerty
2012-02-10 20:44 ` Jeff King
2012-02-10 21:17 ` Junio C Hamano
2012-02-11 6:33 ` Michael Haggerty
2011-12-12 5:38 ` [PATCH v2 29/51] refs: store references hierarchically mhagger
2011-12-12 5:38 ` [PATCH v2 30/51] sort_ref_dir(): do not sort if already sorted mhagger
2011-12-12 23:26 ` Junio C Hamano
2011-12-12 5:38 ` [PATCH v2 31/51] refs: sort ref_dirs lazily mhagger
2011-12-12 5:38 ` [PATCH v2 32/51] do_for_each_ref(): only iterate over the subtree that was requested mhagger
2011-12-12 5:38 ` [PATCH v2 33/51] get_ref_dir(): keep track of the current ref_dir mhagger
2011-12-12 5:38 ` [PATCH v2 34/51] refs: wrap top-level ref_dirs in ref_entries mhagger
2011-12-12 5:38 ` [PATCH v2 35/51] get_packed_refs(): return (ref_entry *) instead of (ref_dir *) mhagger
2011-12-12 5:38 ` [PATCH v2 36/51] get_loose_refs(): " mhagger
2011-12-12 5:38 ` [PATCH v2 37/51] is_refname_available(): take " mhagger
2011-12-12 5:38 ` [PATCH v2 38/51] find_ref(): " mhagger
2011-12-12 5:38 ` [PATCH v2 39/51] read_packed_refs(): " mhagger
2011-12-12 5:38 ` [PATCH v2 40/51] add_ref(): " mhagger
2011-12-12 5:38 ` [PATCH v2 41/51] find_containing_direntry(): use " mhagger
2011-12-12 5:38 ` [PATCH v2 42/51] search_ref_dir(): take " mhagger
2011-12-12 5:38 ` [PATCH v2 43/51] add_entry(): " mhagger
2011-12-12 5:38 ` [PATCH v2 44/51] do_for_each_ref_in_dir*(): " mhagger
2011-12-12 5:38 ` [PATCH v2 45/51] sort_ref_dir(): " mhagger
2011-12-12 5:38 ` [PATCH v2 46/51] struct ref_dir: store a reference to the enclosing ref_cache mhagger
2011-12-12 5:38 ` [PATCH v2 47/51] read_loose_refs(): take a (ref_entry *) as argument mhagger
2011-12-12 5:38 ` [PATCH v2 48/51] refs: read loose references lazily mhagger
2011-12-12 5:38 ` [PATCH v2 49/51] is_refname_available(): query only possibly-conflicting references mhagger
2011-12-12 5:38 ` [PATCH v2 50/51] read_packed_refs(): keep track of the directory being worked in mhagger
2011-12-12 5:38 ` [PATCH v2 51/51] repack_without_ref(): call clear_packed_ref_cache() mhagger
2011-12-12 8:24 ` [PATCH v2 00/51] ref-api-C and ref-api-D re-roll 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=4EE7CDF2.3040408@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=drew.northup@maine.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hvoigt@hvoigt.net \
--cc=jnareb@gmail.com \
--cc=johan@herland.net \
--cc=julian@quantumfyre.co.uk \
--cc=peff@peff.net \
/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).