From: Glen Choo <chooglen@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 2/4] remote: use remote_state parameter internally
Date: Wed, 27 Oct 2021 10:59:22 -0700 [thread overview]
Message-ID: <kl6l35om9wn9.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <xmqq8ryfxkuj.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Glen Choo <chooglen@google.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>>> c) Replace the backpointer with a remote_state parameter. Expressive and
>>>> fits the paradigm of "defaulting to the repo when needed", but
>>>> interfaces are repetitive and shifts the responsibility of
>>>> correctness to the caller (see v2).
> Hopefully. Of course I think the implementation of the safety would
> actually be done, not by iterationg over branches[] array, but just
> checking branch->remote_state == remote_state pointer equality.
With (c), I plan to eliminate the backpointer altogether, so such a
check is not possible. However, I plan to add a branches_hash to
remote_state in the same way that we have remotes_hash for remote_state.
>> This "longer term direction" sounds like what I envisioned with (e). I
>> agree that detached HEAD is a state that should be expressed with more
>> than just NULL, though I'm not sure that "struct branch" is the correct
>> abstraction. No point bikeshedding now of course, we'll cross that
>> bridge when we get there ;)
>
> I actually was hoping that the time to cross the bridge was now,
> though ;-)
Hm, well I don't want to get too lost in the weeds here and lose sight
of the short-term objective. I have a few strands of thought, but
nothing concrete enough to propose a full alternative:
- It seems odd that the branches and the "current_branch" are handled by
the remotes system, perhaps it would be clearer to move it elsewhere.
Separating branches from "branch remote-tracking configuration" might
clarify our thinking.
- branch_get(NULL) and branch_get("HEAD") are not entirely coherent with
the idea of "getting a branch by name", perhaps we should just move
this functionality into a different function.
- Similarly, variants of remote_for_branch() are misleading because they
behave inconsistently when branch is NULL.
I might not want to take action on these ideas though, e.g.
branch_get("HEAD") or remote_for_branch(NULL) are very convenient for
callers even though they behave slightly inconsisently. I'll propose a
longer term direction when I have a better grasp of the system and the
tradeoffs.
next prev parent reply other threads:[~2021-10-27 17:59 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 ` [PATCH v2 0/3] remote: replace static variables with struct remote_state Glen Choo
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 [this message]
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=kl6l35om9wn9.fsf@chooglen-macbookpro.roam.corp.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).