git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2] remote rename: rename branch.<name>.pushRemote config values too

From
Bert Wesarg <bert.wesarg@googlemail.com>
Date
Jan 17, 2020, 14:40 UTC
Message-ID
<CAKPyHN0qY5odXi2wAv20D4nsNM0r4qO_8JOx9DHiGchJmS8cbw@mail.gmail.com>
In-Reply-To
<nycvar.QRO.7.76.6.2001171428170.46@tvgsbejvaqbjf.bet>
Hi,

On Fri, Jan 17, 2020 at 2:30 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 43 quoted lines
>
> Hi Bert,
>
> On Fri, 17 Jan 2020, Bert Wesarg wrote:
>
> > On Fri, Jan 17, 2020 at 12:50 PM Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > Hi Bert,
> > >
> > > On Fri, 17 Jan 2020, Bert Wesarg wrote:
> > >
> > > > When renaming a remote with
> > > >
> > > >     git remote rename X Y
> > > >
> > > > Git already renames any config values from
> > > >
> > > >     branch.<name>.remote = X
> > > >
> > > > to
> > > >
> > > >     branch.<name>.remote = Y
> > > >
> > > > As branch.<name>.pushRemote also names a remote, it now also renames
> > > > these config values from
> > > >
> > > >     branch.<name>.pushRemote = X
> > > >
> > > > to
> > > >
> > > >     branch.<name>.pushRemote = Y
> > >
> > > Should we warn if remote.pushDefault = X?
> >
> > AFAIU, the value of remote.pushDefault wont be renamed yet. So you
> > suggest to issue a warning in case remote.pushDefault is X. But as X
> > does not exists anymore after the rename, the value of
> > remote.pushDefault is invalid. So why not rename it too?
>
> If this setting was usually a repository-specific one, I would suggest to
> change its value, too. But it is my understanding that this might be set
> in `~/.gitconfig` more often than not, so I recommend a warning instead.

than why not rename it, if its a repository-specific setting and warn if it is a global one? If this is detectable at all.

Show 30 quoted lines
>
> > > > @@ -305,7 +309,7 @@ static int config_read_branches(const char *key, const char *value, void *cb)
> > > >                               space = strchr(value, ' ');
> > > >                       }
> > > >                       string_list_append(&info->merge, xstrdup(value));
> > > > -             } else {
> > > > +             } else if (type == REBASE) {
> > > >                       int v = git_parse_maybe_bool(value);
> > > >                       if (v >= 0)
> > > >                               info->rebase = v;
> > > > @@ -315,6 +319,10 @@ static int config_read_branches(const char *key, const char *value, void *cb)
> > > >                               info->rebase = REBASE_MERGES;
> > > >                       else if (!strcmp(value, "interactive"))
> > > >                               info->rebase = INTERACTIVE_REBASE;
> > > > +             } else {
> > > > +                     if (info->push_remote_name)
> > > > +                             warning(_("more than one %s"), orig_key);
> > > > +                     info->push_remote_name = xstrdup(value);
> > >
> > > It makes me a bit nervous that this is an `else` without an `if (type ==
> > > PUSH_REMOTE)`... Maybe do that, just to be on the safe side, even if
> > > another type is introduced in the future?
> >
> > I'm not a friend of this last 'else' either, but it was so to begin
> > with. I'm all for changing it to an 'else if'. Though while it is
> > impossible that 'type' has a value different than one from the enum, I
> > would be even more comfortable with having BUG at the end.
>
> My thinking was: even if this was a bare `else` before, why not fix that
> issue while we're already in the area? I like the `BUG` idea.

Glad I can squash this into this one, instead of making it a single patch out of it.

Bert
>
> Ciao,
> Dscho
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 7 of 15 in “remote: rename also remotes in the branch.<name>.pushRemote config”
  1. remote: rename also remotes in the branch.<name>.pushRemote configBert Wesarg, Jan 16, 2020
  2. Junio C HamanoJan 16, 2020
  3. remote rename: rename branch.<name>.pushRemote config values tooBert Wesarg, Jan 17, 2020
  4. Johannes SchindelinJan 17, 2020
  5. Bert WesargJan 17, 2020
  6. Johannes SchindelinJan 17, 2020
  7. Bert WesargJan 17, 2020
  8. Johannes SchindelinJan 20, 2020
  9. Bert WesargJan 20, 2020
  10. Johannes SchindelinJan 20, 2020
  11. Junio C HamanoJan 17, 2020
  12. Bert WesargJan 17, 2020
  13. Junio C HamanoJan 17, 2020
  14. Johannes SchindelinJan 17, 2020
  15. Johannes SchindelinJan 17, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.