Hi Junio, [re-Cc:ing the list] On Tue, 23 Dec 2014, Junio C Hamano wrote: > On Tue, Dec 23, 2014 at 5:25 AM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html