All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Silva Mendoza <rodrigosilvamendoza3@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: Best way to update `HEAD` in mirrored repos
Date: Tue, 14 Jun 2022 21:11:27 -0700	[thread overview]
Message-ID: <CANWRddMXrhs2grTfq9NtHM7KqxaFRejvaXxvDGV90_m=Kmm-uA@mail.gmail.com> (raw)
In-Reply-To: <xmqq5yl8chhz.fsf@gitster.g>

Hello,

Apologies for the delay, I'd never built Git from source so I put it
off until I had a chunk of time, assuming it might take me a bit -
thankfully it was painless.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Here, you set this up as a fetch mirror. That is something I've missed
> before. It is also important because it means that there is no
> `refs/remotes/origin/HEAD`.

Ahhh, the reason it wasn't working before clicked for me now, thanks
for the explanation.

> diff --git a/builtin/remote.c b/builtin/remote.c
> index eddd40c8f87..fead15adb97 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -1344,7 +1344,7 @@ static int show(int argc, const char **argv)
>
>  static int set_head(int argc, const char **argv)
>  {
> -     int i, opt_a = 0, opt_d = 0, result = 0;
> +     int i, opt_a = 0, opt_d = 0, result = 0, is_mirror = 0;
>       struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
>       char *head_name = NULL;
>
> @@ -1357,8 +1357,16 @@ static int set_head(int argc, const char **argv)
>       };
>       argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
>                            0);
> -     if (argc)
> -             strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
> +     if (argc) {
> +             struct remote *remote = remote_get(argv[0]);
> +
> +             if (!remote || !remote->mirror)
> +                     strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
> +             else {
> +                     is_mirror = 1;
> +                     strbuf_addstr(&buf, "HEAD");
> +             }
> +     }

> Would you have a chance to build Git with this patch and verify that it
> works for you, too?

Good news Johannes, your patch worked for me as well! Here's a run
with the patched code.

    $ git --version
    git version 2.37.0.rc0.dirty
    $ git clone git@github.com:xvandish/livegrep-fragment.git --mirror
    $ cd livegrep-fragment
    $ git symbolic-ref HEAD
    refs/heads/good_main_5
    $ // I changed the github default branch name at this moment
    $ git ls-remote --symref origin HEAD
    ref: refs/heads/good_main_5     HEAD
    0666a519f94b8500ab6f14bdf7c9c2e5ca7d5821        HEAD
    $ git fetch -p
    From github.com:xvandish/livegrep-fragment
    - [deleted]         (none)     -> good_main_4
    * [new branch]      good_main_5 -> good_main_5
    $ git remote set-head -a origin
    origin/HEAD set to good_main_5
    $ git symbolic-ref HEAD
    refs/heads/good_main_5


On Fri, Jun 10, 2022 at 2:53 PM Junio C Hamano <gitster@pobox.com> wrote:
> Good.
>
> Regardless of the "mirror" issue, it makes tons of sense to ask the
> remote API how the remote-tracking refs for the given remote is set
> up, instead of assuming that it must be "refs/remotes/<remote>"
> blindly like in the original code.
>
> That way, we could even handle a case like so:
>
>         [remote "frotz"]
>                 fetch = +refs/heads/*:refs/remotes/nitfol/*
>
> Their HEAD should be mapped to refs/remotes/nitfol/HEAD on our end,
> so set-head should be able to notice that, too, if we go further
> with your "do not assume, instead ask remote API" approach.
>
> Thanks.

This makes sense to me as well, as a continuation of the "ask remote " style.
I only have a very vague idea of how I'd implement this from a look at
the codebase, so I'd be of more
help testing things out. If this idea carries forward let me know if I
can be of help testing, or if you'd like me to
like me to try to put a patch up let me know.


Thanks to both of you for your time.

  reply	other threads:[~2022-06-15  4:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 20:36 Best way to update `HEAD` in mirrored repos Rodrigo Silva Mendoza
2022-06-08 22:53 ` Junio C Hamano
2022-06-09  5:01   ` Rodrigo Silva Mendoza
2022-06-09  8:02 ` Johannes Schindelin
2022-06-09 14:46   ` Rodrigo Silva Mendoza
2022-06-10 21:46     ` Johannes Schindelin
2022-06-10 21:53       ` Junio C Hamano
2022-06-15  4:11         ` Rodrigo Silva Mendoza [this message]
2022-06-15  4:18           ` Rodrigo Silva Mendoza

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

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

  git send-email \
    --in-reply-to='CANWRddMXrhs2grTfq9NtHM7KqxaFRejvaXxvDGV90_m=Kmm-uA@mail.gmail.com' \
    --to=rodrigosilvamendoza3@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.