On 12-07-06 03:39 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com 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?
Erm, actually, my statement is incorrect. Doh!
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_.
Yes, true.
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),
Are you talking about the sub-thread Phil Hord I spawned about patch #4? I
think Phil I are in agreement there that it is the right thing to do. If
anyone disagrees please speak up!
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'?
The proposed code actually already does that. I'll add a unit test for this
case.
So why change git clone to always set remote.default if the functionality
remains the same either way?
To me it makes a more consistent implementation. Since git remote add sets
remote.default if it's adding the first remote to the repository, when clone
itself adds the first remote it should do the same.
Plus this approach makes clone -o also work without any special-casing, so
the code is cleaner, IMHO.
If this justification is adequate, I'll add it to the commit message. It may
then make more sense to have this commit come after the git remote changes
in the series.
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?
I agree with that requirement, and believe the proposed code fulfils it.
M.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
