git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH 2/2] worktree.c: use submodule interface to access refs from another worktree
Date: Thu, 9 Feb 2017 15:03:50 +0100	[thread overview]
Message-ID: <4bea30e9-9724-0a71-e9da-d79ad8accd28@alum.mit.edu> (raw)
In-Reply-To: <CACsJy8Diy92CNbJ1OBn893VFFrSsxBFWSyQHjt_Dzq9x7jfibQ@mail.gmail.com>

On 02/09/2017 12:59 PM, Duy Nguyen wrote:
> On Thu, Feb 9, 2017 at 1:07 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> It is unquestionably a good goal to avoid parsing references outside of
>> `refs/files-backend.c`. But I'm not a fan of this approach.
> 
> Yes. But in this context it was more of a guinea pig. I wanted
> something simple enough to code up show we can see what the approach
> looked like. Good thing I did it.
> 
>>
>> There are two meanings of the concept of a "ref store", and I think this
>> change muddles them:
>>
>> 1. The references that happen to be *physically* stored in a particular
>>    location, for example the `refs/bisect/*` references in a worktree.
>>
>> 2. The references that *logically* should be considered part of a
>>    particular repository. This might require stitching together
>>    references from multiple sources, for example `HEAD` and
>>    `refs/bisect` from a worktree's own directory with other
>>    references from the main repository.
>>
>> Either of these concepts can be implemented via the `ref_store` abstraction.
>>
>> The `ref_store` for a submodule should represent the references
>> logically visible from the submodule. The main program shouldn't care
>> whether the references are stored in a single physical location or
>> spread across multiple locations (for example, if the submodule were
>> itself a linked worktree).
>>
>> The `ref_store` that you want here for a worktree is not the worktree's
>> *logical* `ref_store`. You want the worktree's *physical* `ref_store`.
> 
> Yep.
> 
>> Mixing logical and physical reference stores together is a bad idea
>> (even if we were willing to ignore the fact that worktrees are not
>> submodules in the accepted sense of the word).
>>
>> ...
>>
>> I think the best solution would be to expose the concept of `ref_store`
>> in the public refs API. Then users of submodules would essentially do
>>
>>     struct ref_store *refs = get_submodule_refs(submodule_path);
>>     ... resolve_ref_recursively(refs, refname, 0, sha1, &flags) ...
>>     ... for_each_ref(refs, fn, cb_data) ...
>>
>> whereas for a worktree you'd have to look up the `ref_store` instance
>> somewhere else (or maybe keep it as part of some worktree structure, if
>> there is one) but you would use it via the same API.
> 
> Oh I was going to reply to Stefan about his comment to my (**)
> footnote. Something along the this line
> 
> "Ideally we would introduce a new set of api, maybe with refs_ prefix,
> that takes a refs_store. Then submodule people can get a ref store
> somewhere and pass to it. Worktree people get maybe some other refs
> store for it. The "old" api like for_each_ref() is a thin wrapper
> around it, just like read_cache() vs read_index(&the_index). If the
> *_submodule does not see much use, we might as well kill it and use
> the generic refs_*".
> 
> If I didn't misunderstood anything else, then I think we're on the same page.
> 
> Now I need to see if I can get there in a reasonable time frame (so I
> can fix my "gc in worktree" problem properly) or I would need
> something temporary but not so hacky. I'll try to make this new api
> and see how it works out. If you think I should not do it right away,
> for whatever reason, stop me now.

Sounds good. A couple of hints and points to remember:

* I think `struct ref_store *` should remain opaque outside of the refs
  code.

* The virtual function interface embodied in `struct ref_storage_be`
  isn't meant to be an external interface (i.e., don't just expose it
  and have external callers use it directly).

* One important distinction between the main reference store and
  submodule reference stores is that we know the object store for
  the former but not the latter. That implies that some operations
  are, or should be, impossible for submodules (e.g., anything that
  involves looking up objects, including peeling refs). However, we
  *do* know the object store for linked worktrees. So they don't have
  to be as dumbed-down as submodule ref stores. (This might be
  irrelevant if you don't need any additional features for your
  current purposes.)

Also, I just sent my submodule-hash patch series to the mailing list in
case you want to build on that.

Michael


  reply	other threads:[~2017-02-09 14:05 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-08 11:31 [PATCH RFC 0/2] Kill manual ref parsing code in worktree.c Nguyễn Thái Ngọc Duy
2017-02-08 11:31 ` [PATCH 1/2] refs.c: add resolve_ref_submodule() Nguyễn Thái Ngọc Duy
2017-02-09  5:20   ` Michael Haggerty
2017-02-08 11:31 ` [PATCH 2/2] worktree.c: use submodule interface to access refs from another worktree Nguyễn Thái Ngọc Duy
2017-02-08 19:50   ` Stefan Beller
2017-02-08 23:19     ` Junio C Hamano
2017-02-08 23:25   ` Junio C Hamano
2017-02-09  6:07   ` Michael Haggerty
2017-02-09  6:55     ` Junio C Hamano
2017-02-09  8:04       ` Michael Haggerty
2017-02-09 11:59     ` Duy Nguyen
2017-02-09 14:03       ` Michael Haggerty [this message]
2017-02-08 18:18 ` [PATCH RFC 0/2] Kill manual ref parsing code in worktree.c Junio C Hamano
2017-02-16 12:02 ` [PATCH v2 0/5] " Nguyễn Thái Ngọc Duy
2017-02-16 12:02   ` [PATCH v2 1/5] refs: introduce get_worktree_ref_store() Nguyễn Thái Ngọc Duy
2017-02-16 12:02   ` [PATCH v2 2/5] refs.c: add refs_resolve_ref_unsafe() Nguyễn Thái Ngọc Duy
2017-02-16 12:03   ` [PATCH v2 3/5] worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe() Nguyễn Thái Ngọc Duy
2017-02-16 12:03   ` [PATCH v2 4/5] refs: add refs_create_symref() Nguyễn Thái Ngọc Duy
2017-02-16 12:03   ` [PATCH v2 5/5] refs: kill set_worktree_head_symref() Nguyễn Thái Ngọc Duy
2017-03-18 10:02   ` [PATCH v3 0/4] Kill manual ref parsing code in worktree.c Nguyễn Thái Ngọc Duy
2017-03-18 10:02     ` [PATCH v3 1/4] environment.c: fix potential segfault by get_git_common_dir() Nguyễn Thái Ngọc Duy
2017-03-18 17:54       ` Junio C Hamano
2017-03-19  9:34         ` Duy Nguyen
2017-03-18 10:02     ` [PATCH v3 2/4] refs: introduce get_worktree_ref_store() Nguyễn Thái Ngọc Duy
2017-03-20  6:59       ` Michael Haggerty
2017-03-20 12:01         ` Duy Nguyen
2017-03-20 14:25           ` Michael Haggerty
2017-03-26  8:26             ` Duy Nguyen
2017-03-18 10:02     ` [PATCH v3 3/4] worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe() Nguyễn Thái Ngọc Duy
2017-03-18 10:02     ` [PATCH v3 4/4] refs: kill set_worktree_head_symref() Nguyễn Thái Ngọc Duy
2017-03-18 17:49     ` [PATCH v3 0/4] Kill manual ref parsing code in worktree.c Junio C Hamano
2017-04-04 10:21     ` [PATCH v4 0/5] " Nguyễn Thái Ngọc Duy
2017-04-04 10:21       ` [PATCH v4 1/5] environment.c: fix potential segfault by get_git_common_dir() Nguyễn Thái Ngọc Duy
2017-04-04 10:21       ` [PATCH v4 2/5] refs.c: make submodule ref store hashmap generic Nguyễn Thái Ngọc Duy
2017-04-04 10:21       ` [PATCH v4 3/5] refs: introduce get_worktree_ref_store() Nguyễn Thái Ngọc Duy
2017-04-22  4:52         ` Michael Haggerty
2017-04-04 10:21       ` [PATCH v4 4/5] worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe() Nguyễn Thái Ngọc Duy
2017-04-04 10:21       ` [PATCH v4 5/5] refs: kill set_worktree_head_symref() Nguyễn Thái Ngọc Duy
2017-04-14  1:40       ` [PATCH v4 0/5] Kill manual ref parsing code in worktree.c Junio C Hamano
2017-04-14  2:02         ` Junio C Hamano
2017-04-14 12:45           ` Duy Nguyen
2017-04-17  1:36             ` Junio C Hamano
2017-04-22  5:06         ` Michael Haggerty
2017-04-24 10:01       ` [PATCH v5 0/6] " Nguyễn Thái Ngọc Duy
2017-04-24 10:01         ` [PATCH v5 1/6] environment.c: fix potential segfault by get_git_common_dir() Nguyễn Thái Ngọc Duy
2017-04-24 10:01         ` [PATCH v5 2/6] refs.c: make submodule ref store hashmap generic Nguyễn Thái Ngọc Duy
2017-04-24 10:01         ` [PATCH v5 3/6] refs: add REFS_STORE_ALL_CAPS Nguyễn Thái Ngọc Duy
2017-04-24 10:01         ` [PATCH v5 4/6] refs: introduce get_worktree_ref_store() Nguyễn Thái Ngọc Duy
2017-04-24 10:01         ` [PATCH v5 5/6] worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe() Nguyễn Thái Ngọc Duy
2017-04-24 10:01         ` [PATCH v5 6/6] refs: kill set_worktree_head_symref() Nguyễn Thái Ngọc Duy
2017-04-25  4:30         ` [PATCH v5 0/6] Kill manual ref parsing code in worktree.c 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4bea30e9-9724-0a71-e9da-d79ad8accd28@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=sbeller@google.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).