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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

>> > 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.

Oh, don't get me wrong.  I do not have any interest in allowing
re-adding remotes, either, so we are on the same page.

I was just saying that it was unclear what ensures that the change
in the codepath only affects the remote setting that conflicts with
"insteadOf" without randomly (read: sometimes it allows, sometimes
it forbids) allowing re-adding remotes.
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]