On Wed Sep 11, 2024 at 08:54, Jeff King <peff@xxxxxxxx> wrote:
> On Tue, Sep 10, 2024 at 10:24:58PM +0200, Bence Ferdinandy wrote:
>
> > When cloning a repository refs/remotes/origin/HEAD is set automatically.
> > In contrast, when using init, remote add and fetch to set a remote, one
> > needs to call remote set-head --auto to achieve the same result.
>
> Yes, I think this is a good goal, but...
>
> > diff --git a/builtin/fetch.c b/builtin/fetch.c
> > index b2b5aee5bf..6392314c6a 100644
> > --- a/builtin/fetch.c
> > +++ b/builtin/fetch.c
> > @@ -1961,8 +1961,19 @@ static int fetch_finished(int result, struct strbuf *out,
> > return 0;
> > }
> >
> > -static int fetch_multiple(struct string_list *list, int max_children,
> > - const struct fetch_config *config)
> > +static int run_set_head(const char *name)
> > +{
> > + struct child_process cmd = CHILD_PROCESS_INIT;
> > + strvec_push(&cmd.args, "remote");
> > + strvec_push(&cmd.args, "set-head");
> > + strvec_push(&cmd.args, "--auto");
> > + strvec_push(&cmd.args, name);
> > + cmd.git_cmd = 1;
> > + return run_command(&cmd);
> > +}
>
> ...this is just calling "git remote" to do the real work. Which means
> that git-remote is going to make its own separate connection to the
> server (so slow, but may also require the user to reauthenticate, etc).
And indeed it does authenticate the user twice. I'll change this in a v3 (see
the discussion on v2, I royally messed up CC address on this one :) ).
>
> I think the intent of your patch 2 is that we'd only invoke this when we
> saw a change, which mitigates the impact, but it still seems somewhat
> hacky to me. We already have all of the information we need to do the
> update inside fetch itself.
It was more about not printing slightly misleading information, it did still
always try to get the new information with --auto. With the changes mentioned
in the other thread I'll also rework this a bit.
Best,
Bence
