Re: [PATCH 0/1] New remote groups subcommand

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2025, 16:32 UTC
Message-ID: <xmqqecx3ow6u.fsf@gitster.g>
In-Reply-To: <20250503160953.196329-1-bugzilla@lazar.co.nz>

Lazar Sumar <sumar@lazar.co.nz> writes:

Show 13 quoted lines

> Lastly, I wanted to at least add a test for the expected behavior of
> remote grups when a remote is renamed but found the current behavior
> surprising, i.e.
>
>     $ git config --get-regexp 'remotes\.'
>     file:.git/config        remotes.group1 upstream origin
>     $ git remote rename origin fork
>     Renaming remote references: 100% (8/8), done.
>     $ git config --get-regexp 'remotes\.'
>     file:.git/config        remotes.group1 upstream origin
>
> The remote group is defined in the local config file and I would expect
> the rename to rename the group member here.

Even for a single same person, depending on the reason why the renaming of the underlying individual remote nickname is done, I think the expectation is different. Perhaps they have a set of remotes that they use for CI use (i.e., they push there to trigger multiple CI platforms), that are named ci-alfa ci-beta etc. to make it easier for them to identify these remotes, and grouped under "ci" group, and they have another group they use for publishing (i.e., they push there and the latest history becomes available to their developers), as "publish" group. Suppose they decide to retire the CI infrastructure from the ci-alfa remote and use the repository only for publishing. Then the config setting that may have looked like this

	[remotes]
		ci = ci-alfa ci-beta ...
		publish = north-america europe ...

would want to become

	[remotes]
		ci = ci-beta ...
		publish = asia north-america europe ...

when they rename "ci-alfa" to "asia" because they no longer have CI infrastructure attached to the repository to trigger, and instead they want to use the repository to serve asian customers.

If "git remote rename ci-alfa asia" automatically rewrote the first one to

	[remotes]
		ci = asia ci-beta ...
		publish = north-america europe ...

it would not help anybody.

Of course, if the renaming is done to fix typo in the name of a remote, e.g., "git remote rename ci-alfa ci-alpha", it would be useful if the rename also rewrote the config into

	[remotes]
		ci = ci-alpha ci-beta ...
		publish = north-america europe ...

but we cannot guess the intentions. So I am not sure if always automatically rewriting is a good idea.

Before thinking about "rename" doing random things that the user may or may not want to see perform automatically, I think it is better to give users a way to exactly do what they want first. Perhaps a session with those tools would look like this?

    $ git remote group --list
    ci
    publish
    $ git remote group --list --verbose
    ci		ci-alfa ci-beta
    publish	north-america europe
    $ git remote group --get ci
    ci-alfa
    ci-beta
    $ git remote group --set ci ci-alfa ci-beta
    $ git remote group --get ci
    ci-alpha
    ci-beta
    $ git remote group --list
    ci
    publish
    $ git remote group --rename publish pub
    $ git remote group --list
    ci
    pub