git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Glen Choo <chooglen@google.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, Glen Choo <chooglen@google.com>
Subject: [PATCH v2 0/3] remote: replace static variables with struct remote_state
Date: Wed, 13 Oct 2021 12:31:24 -0700	[thread overview]
Message-ID: <20211013193127.76537-1-chooglen@google.com> (raw)
In-Reply-To: <pull.1103.git.git.1633633635.gitgitgadget@gmail.com>

This series aims to make the remotes subsystem work with
non-the_repository, which will allow submodule remotes to be accessed
in-process, rather than through child processes. This is accomplished by
creating a struct remote_state and adding it to struct repository.

One motivation for this is that it allows future submodule commands to run
in-process. An example is an RFC series of mine [1], where I tried to implement
"git branch --recurse-submodules" in-process but couldn't figure out how to
read the remotes of a submodule.

v2 aims to catch all of the instances of struct remote_state that I had
missed in v1, particularly with the struct branch functions. Because
more repo_* functions were added, the preparatory patches have been
reorganized.

In this version, my biggest uncertainty is in the interfaces of the
repo_* functions. Some functions expect a "struct repository" and one
of its contained members (e.g. "struct branch"). This interface allows
for incorrect behavior if the caller supplies a "struct repository"
instance that is unrelated from the "struct branch". This concern was
raised by Junio in [2].

While this concern is valid, I decided to keep this interface for a few
reasons:

1. The correct way of calling the function is 'obvious'.
2. It is relatively easy to get the contained object (struct branch/remote)
   and its containing struct repository/remote_state (e.g. we don't pass
   struct branch or remote through long call chains). For "struct
   branch", callers usually get the branch from the repo and use it
   immediately. For "struct remote", we don't use container objects
   outside of static functions. If you are interested in seeing all of
   the call sites, you can see a sample commit in [3].
3. The separation between container/contained objects allows us to
   reason better about what the correct interface is. e.g. we might be
   tempted to include a backpointer from struct branch to struct
   remote_state so that we can pass around struct branch and be
   confident that struct branch has all of the information it needs.

   However, I believe that some questions *shouldn't* be answered by
   just struct branch. The prime example in this series is
   branch_get_push() - it conceptually answers 'What is the pushremote
   of this branch', but the behavior we want is closer to 'If
   configured, give me the pushremote for the branch. Otherwise, give me
   the default pushremote of the repo.'. This is arguably a relevant
   detail that should be exposed to callers.

If we want the interface to prevent misuse, we can check that the
correct repository is passed at runtime. Alternatively, if we are
convinced that some questions can only be answered in the context of a
repository, we can take things one step further by using (struct
repository, branch_name) instead of (struct repository, struct branch).

A different concern is that struct repository is added to some callback
signatures even though the function body doesn't use it e.g.
repo_remote_for_branch(). However, this might be more of an accident of
history than anything else - the difference between remote and
pushremote is that remote always defaults to 'origin', whereas
the default value of pushremote is configurable.

Changes since v1:

* In v1, we moved static variables into the_repository->remote_state in
  two steps: static variables > static remote_state >
  the_repository->remote_state. In v2, make this change in one step:
  static variables > the_repository->remote_state.
* Add more instances of repo_* that were missed.

[1] https://lore.kernel.org/git/20210921232529.81811-1-chooglen@google.com/
[2] https://lore.kernel.org/git/xmqq4k9so15i.fsf@gitster.g/
[3] https://github.com/chooglen/git/commit/173e0268fd076044dd6b3cae893eedfa33965942

Glen Choo (3):
  remote: move static variables into per-repository struct
  remote: use remote_state parameter internally
  remote: add struct repository parameter to external functions

 remote.c     | 305 +++++++++++++++++++++++++++++++--------------------
 remote.h     | 130 +++++++++++++++++++---
 repository.c |   8 ++
 repository.h |   4 +
 4 files changed, 312 insertions(+), 135 deletions(-)

Range-diff against v1:
1:  6972ba4dcb = 1:  6972ba4dcb remote: move static variables into per-repository struct
2:  71b1da4389 = 2:  71b1da4389 remote: use remote_state parameter internally
3:  ff12771f06 = 3:  ff12771f06 remote: add struct repository parameter to external functions
-- 
2.33.0.882.g93a45727a2-goog


  parent reply	other threads:[~2021-10-13 19:31 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07 19:07 [PATCH 0/2] remote: replace static variables with struct remote_state Glen Choo via GitGitGadget
2021-10-07 19:07 ` [PATCH 1/2] remote: move static variables into struct Glen Choo via GitGitGadget
2021-10-07 23:36   ` Junio C Hamano
2021-10-07 19:07 ` [PATCH 2/2] remote: add remote_state to struct repository Glen Choo via GitGitGadget
2021-10-07 23:39   ` Junio C Hamano
2021-10-08 17:30     ` Glen Choo
2021-10-13 19:31 ` Glen Choo [this message]
2021-10-13 19:31   ` [PATCH v2 1/3] remote: move static variables into per-repository struct Glen Choo
2021-10-13 20:21     ` Junio C Hamano
2021-10-14 17:25       ` Glen Choo
2021-10-14 18:33         ` Junio C Hamano
2021-10-13 19:31   ` [PATCH v2 2/3] remote: use remote_state parameter internally Glen Choo
2021-10-13 20:23     ` Junio C Hamano
2021-10-13 19:31   ` [PATCH v2 3/3] remote: add struct repository parameter to external functions Glen Choo
2021-10-13 20:24     ` Junio C Hamano
2021-10-13 20:11   ` [PATCH v2 0/3] remote: replace static variables with struct remote_state Junio C Hamano
2021-10-13 20:27     ` Junio C Hamano
2021-10-13 22:00       ` Glen Choo
2021-10-13 21:56     ` Glen Choo
2021-10-13 23:37       ` Junio C Hamano
2021-10-14  1:25         ` Glen Choo
2021-10-19 22:43   ` [PATCH v3 0/4] " Glen Choo
2021-10-19 22:43     ` [PATCH v3 1/4] remote: move static variables into per-repository struct Glen Choo
2021-10-19 22:43     ` [PATCH v3 2/4] remote: use remote_state parameter internally Glen Choo
2021-10-20 19:45       ` Junio C Hamano
2021-10-20 20:31         ` Junio C Hamano
2021-10-20 22:08           ` Junio C Hamano
2021-10-25 18:09           ` Glen Choo
2021-10-25 19:36             ` Glen Choo
2021-10-25 20:33               ` Junio C Hamano
2021-10-25 23:00                 ` Glen Choo
2021-10-26  0:45                   ` Junio C Hamano
2021-10-26  1:22                     ` Junio C Hamano
2021-10-26 17:04                       ` Glen Choo
2021-10-27  2:28                         ` Junio C Hamano
2021-10-27 17:59                           ` Glen Choo
2021-10-27 20:03                             ` Junio C Hamano
2021-10-19 22:43     ` [PATCH v3 3/4] remote: remove the_repository->remote_state from static methods Glen Choo
2021-10-19 22:43     ` [PATCH v3 4/4] remote: add struct repository parameter to external functions Glen Choo
2021-10-28 18:30     ` [PATCH v4 0/6] remote: replace static variables with struct remote_state Glen Choo
2021-10-28 18:30       ` [PATCH v4 1/6] t5516: add test case for pushing remote refspecs Glen Choo
2021-10-28 20:17         ` Junio C Hamano
2021-11-15 18:42         ` Jonathan Tan
2021-11-15 20:09           ` Glen Choo
2021-10-28 18:30       ` [PATCH v4 2/6] remote: move static variables into per-repository struct Glen Choo
2021-10-28 18:30       ` [PATCH v4 3/6] remote: use remote_state parameter internally Glen Choo
2021-10-28 18:30       ` [PATCH v4 4/6] remote: remove the_repository->remote_state from static methods Glen Choo
2021-11-15 18:48         ` Jonathan Tan
2021-10-28 18:31       ` [PATCH v4 5/6] remote: die if branch is not found in repository Glen Choo
2021-11-15 18:50         ` Jonathan Tan
2021-11-15 20:06           ` Glen Choo
2021-11-16 17:45             ` Jonathan Tan
2021-10-28 18:31       ` [PATCH v4 6/6] remote: add struct repository parameter to external functions Glen Choo
2021-11-15 18:55         ` Jonathan Tan
2021-11-15 21:44           ` Glen Choo
2021-11-12  0:01       ` [PATCH v4 0/6] remote: replace static variables with struct remote_state Glen Choo

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=20211013193127.76537-1-chooglen@google.com \
    --to=chooglen@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).