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

[Junio C Hamano <gitster@pobox.com>]

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

> 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