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

Re: [PATCH 1/2] git remote add: allow re-adding remotes with the same URL

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Dec 23, 2014, 18:26 UTC
Message-ID
<alpine.DEB.1.00.1412231923560.21312@s15462909.onlinehome-server.info>
In-Reply-To
<CAPc5daXcXs+Sw8jr65dmLnpf6LQ6Lr34y80bxSf2AhhFyXa_mQ@mail.gmail.com>
Hi Junio,
[re-Cc:ing the list]
On Tue, 23 Dec 2014, Junio C Hamano wrote:
Show 26 quoted lines
> On Tue, Dec 23, 2014 at 5:25 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 22 Dec 2014, Junio C Hamano wrote:
> >>
> >> So, it is an error if we have "remote" and if
> >>
> >>  (1) URL for the remote is defined already twice or more; or
> >>  (2) we are adding a nickname (i.e. not a URL) and it is different
> >>      from what we already have; or
> >>  (3) we already have fetch_refspec
> >>
> >> The way I read the log message's rationale was that this is to allow
> >> replacing an existing remote's URL; wouldn't checking the existence
> >> of fetch_refspec go against that goal?
> >>
> >> Puzzled.  Either the code is wrong or I am mislead by the
> >> explanation in the log.
> >
> > I hope v2 addresses your concerns.
> 
> Unfortunately I am still confused.
> 
> The way the overlong line is folded in the new version of the patch
> makes it easier to read, but I didn't find a reason why checking the
> number of fetch_refspec does not go against that goal there.

Since you pointed out rightfully that the main goal is *not* to allow multiple `git remote add` to succeed when they try to add the same remote with the same URL, I changed the commit message to point out that the goal was to handle adding remotes via `git remote add <nick> <url>` when url.<url>.insteadOf = <nick> already exists, with the same <nick> and <url>.

Since I have no interest in opening the can of worms to allow re-adding remotes, I did not touch that part at all, I hope you do not mind.

Ciao, Dscho

Previous: Johannes SchindelinNext: Junio C Hamano
Message 18 of 19 in “remote: allow adding remote w same name as alias”
  1. remote: allow adding remote w same name as aliasAnastas Dancha, Dec 16, 2014
  2. Johannes SchindelinDec 16, 2014
  3. Anastas DanchaDec 16, 2014
  4. Johannes SchindelinDec 19, 2014
  5. Anastas DanchaDec 19, 2014
  6. Michael J GruberDec 19, 2014
  7. Anastas DanchaDec 20, 2014
  8. Johannes SchindelinDec 21, 2014
  9. Michael J GruberDec 16, 2014
  10. 0/2 Let `git remote add` play nicer with url.<url>.insteadOfJohannes Schindelin, Dec 22, 2014
  11. 1/2 git remote add: allow re-adding remotes with the same URLJohannes Schindelin, Dec 22, 2014
  12. Junio C HamanoDec 22, 2014
  13. Johannes SchindelinDec 23, 2014
  14. 2/2 Add a regression test for 'git remote add <existing> <same-url>'Johannes Schindelin, Dec 22, 2014
  15. 0/2 Let `git remote add` play nicer with url.<url>.insteadOfJohannes Schindelin, Dec 23, 2014
  16. 1/2 git remote: allow adding remotes agreeing with url.<...>.insteadOfJohannes Schindelin, Dec 23, 2014
  17. 2/2 Add a regression test for 'git remote add <existing> <same-url>'Johannes Schindelin, Dec 23, 2014
  18. Johannes SchindelinDec 23, 2014
  19. Junio C HamanoDec 23, 2014

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.