Re: [PATCH 3/6] Teach clone to set remote.default.

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

 



Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:

> If remote.default isn't set, then if someone does
> 		git remote rename origin foo
> the default remote will still be "origin" (modulo the currently-checked-out
> branch stuff).

Why?  I thought the proposed semantics was "if remote.default is
unset, the default value of 'origin' is used where remote.default
would have been used _everywhere_".  If "remote rename" wants to
update the value of remote.default from 'origin' to 'foo' (which may
or may not be the right thing to do, for which a separate discussion
seems to exist already), and if it sees that the repository does not
have remote.default, shouldn't it still set it to 'foo', just like
the case where remote.default exists and set to 'origin'?

Your updated "remote rename" must work correctly in a repository
that was created long ago, where remote.default was not set to
anything (and default 'origin' was used) after all.

Or am I missing some subtle issues?
--
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]