git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 9/9] cache.h: allow sha1_object_info to handle arbitrary repositories

From
BWBrandon Williams <bmwill@google.com>
Date
Apr 24, 2018, 18:42 UTC
Message-ID
<20180424184233.GA90854@google.com>
In-Reply-To
<20180424112332.38c0d04d96689f030e96825a@google.com>
On 04/24, Jonathan Tan wrote:
Show 12 quoted lines
> On Mon, 23 Apr 2018 16:43:27 -0700
> Stefan Beller <sbeller@google.com> wrote:
> 
> > This involves also adapting sha1_object_info_extended and a some
> > internal functions that are used to implement these. It all has to
> > happen in one patch, because of a single recursive chain of calls visits
> > all these functions.
> 
> In packfile.c, unpack_entry() invokes get_delta_base_cache_entry(),
> which references a global (delta_base_cache). Does delta_base_cache need
> to be moved to the repo object (or object store object) first, or is
> this safe?

After looking at this, I think it should be safe for now since its a cache that requires a packed_git pointer to access (and those would be per repository). We may want to move it in to the repository at some point though.

Show 8 quoted lines
> 
> Also, in sha1_file.c, oid_object_info_extended() invokes fetch_object(),
> which attempts to fetch a missing object. For this, I think that it's
> best to guard with a "r == the_repository" check, or if there's a better
> way to distinguish between the "default" repository and any repository
> that we newly create (I vaguely remember some distinction when parsing
> environment variables when determining repo paths - the envvars were
> only used for the "default" repository, but not for the others).

This is a little more difficult and I'm not sure I know what the best course of action would be for this. Mostly because then this puts a big recursive dependency on the whole fetch mechanism to handle arbitrary repositories at the same time these functions are converted. So maybe throwing in the runtime check would be the best way to break the dependencies for now.

-- 
Brandon Williams
Previous: Jonathan TanNext: Jonathan Tan
Message 18 of 19 in “object store: oid_object_info is the next contender”
  1. 0/9 object store: oid_object_info is the next contenderStefan Beller, Apr 23, 2018
  2. 1/9 cache.h: add repository argument to oid_object_info_extendedStefan Beller, Apr 23, 2018
  3. 2/9 cache.h: add repository argument to oid_object_infoStefan Beller, Apr 23, 2018
  4. brian m. carlsonApr 24, 2018
  5. Jonathan TanApr 24, 2018
  6. 3/9 packfile: add repository argument to retry_bad_packed_offsetStefan Beller, Apr 23, 2018
  7. 6/9 packfile: add repository argument to read_objectStefan Beller, Apr 23, 2018
  8. 5/9 packfile: add repository argument to packed_object_infoStefan Beller, Apr 23, 2018
  9. Jonathan TanApr 24, 2018
  10. Junio C HamanoApr 25, 2018
  11. 4/9 packfile: add repository argument to packed_to_object_typeStefan Beller, Apr 23, 2018
  12. 7/9 packfile: add repository argument to unpack_entryStefan Beller, Apr 23, 2018
  13. 8/9 packfile: add repository argument to cache_or_unpack_entryStefan Beller, Apr 23, 2018
  14. 9/9 cache.h: allow sha1_object_info to handle arbitrary repositoriesStefan Beller, Apr 23, 2018
  15. brian m. carlsonApr 24, 2018
  16. Stefan BellerApr 24, 2018
  17. Jonathan TanApr 24, 2018
  18. Brandon WilliamsApr 24, 2018
  19. Jonathan TanApr 24, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.