Re: [PATCH 01/10] contrib: remove "remotes2config.sh"

From: Patrick Steinhardt <ps@pks.im>
Date: May 7, 2025, 06:27 UTC
Message-ID: <aBr9VuYurCCvRYnj@pks.im>
In-Reply-To: <xmqqr011ikjc.fsf@gitster.g>

On Tue, May 06, 2025 at 12:52:39PM -0700, Junio C Hamano wrote:

Show 34 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Remotes can be configured either via a repository's config or by using
> > the ".git/branches/" or ".git/remotes/" directories. Back when the new
> > config-based mechanism has been introduced we also introduced a helper
> > script that migrates from the old-style remote configuration to the new
> > config-based mechanism.
> >
> > With the recent removal announcement for the two directories we also
> > started to instruct users to migrate repositories that still use these
> > mechanism to use config-based remotes. Notably though, the migration
> > path doesn't even use the migration script. Instead, git-remote(1)
> > itself knows how to migrate any such remote via `git remote rename`.
> 
> Makes sense.
> 
> This logically comes after your series, which ended at 8ccc75c2
> (remote: announce removal of "branches/" and "remotes/",
> 2025-01-22), lands.  After that, we can safely remove this script at
> the 3.0 boundary, at the same time we clean up the code paths that
> are conditionally compiled with WITH_BREAKING_CHANGES.
> 
> > Furthermore, the script hasn't been touched since afa75bc8aa1 (contrib:
> > Make remotes2config.sh script more robust, 2007-12-02).
> 
> A single-purpose thing that is done correctly on top of a right
> abstraction does not necessarily need further updates, so I doubt
> this paragraph contributes to the decision to remove the script in
> any way.
> 
> > Given that there is a migration path without this script it is very
> > unlikely that anyone still uses the script. Remove it.
> 
> Sounds good, but not right now, I presume?

I think it should be fine to remove it right now. If it was the canonical way to migrate repos to the new format we definitely shouldn't. But nowhere in our tree do we even point to this script, and the deprecation notice we have created explicitly tells users to use `git remote rename`:

    static void warn_about_deprecated_remote_type(const char *type,
                              const struct remote *remote)
    {
        warning(_("reading remote from \"%s/%s\", which is nominated for removal.\n"
              "\n"
              "If you still use the \"remotes/\" directory it is recommended to\n"
              "migrate to config-based remotes:\n"
              "\n"
              "\tgit remote rename %s %s\n"
              "\n"
              "If you cannot, please let us know why you still need to use it by\n"
              "sending an e-mail to <git@vger.kernel.org>."),
            type, remote->name, remote->name, remote->name);
    }

So I highly doubt this script plays any role in the migration towards config-based remotes. Also because the script only cares about the "remotes/" directory -- it doesn't even know to migrate remotes from "branches/".

Another data point: the script doesn't even work as-is, as it sources ". git-sh-setup". So for it to work it would need to be installed into "$prefix/libexec/git-core" together with our other tools, or it needs to be called so that "git-sh-setup" is in the user's PATH. Both of which seems quite unlikely to me.

All of this reasoning should of course go into the commit message.

Patrick