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

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

From
Marc Branchaud <marcnarc@xiplink.com>
Date
Jul 6, 2012, 20:43 UTC
Message-ID
<4FF74DD4.1060800@xiplink.com>
In-Reply-To
<7vd348of0z.fsf@alter.siamese.dyndns.org>
On 12-07-06 03:39 PM, Junio C Hamano wrote:
Show 8 quoted lines
> Marc Branchaud <marcnarc@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.

Show 5 quoted lines
> 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.
Previous: Junio C HamanoNext: Marc Branchaud
Message 12 of 18 in “Default remote”
  1. 0/6 Default remotemarcnarc@xiplink.com, Jul 5, 2012
  2. 1/6 Rename remote.c's default_remote_name static variables.marcnarc@xiplink.com, Jul 5, 2012
  3. 2/6 Teach remote.c about the remote.default configuration setting.marcnarc@xiplink.com, Jul 5, 2012
  4. Junio C HamanoJul 5, 2012
  5. Marc BranchaudJul 6, 2012
  6. Junio C HamanoJul 6, 2012
  7. Marc BranchaudJul 6, 2012
  8. 3/6 Teach clone to set remote.default.marcnarc@xiplink.com, Jul 5, 2012
  9. Junio C HamanoJul 5, 2012
  10. Marc BranchaudJul 6, 2012
  11. Junio C HamanoJul 6, 2012
  12. Marc BranchaudJul 6, 2012
  13. Marc BranchaudJul 6, 2012
  14. 4/6 Teach "git remote" about remote.default.marcnarc@xiplink.com, Jul 5, 2012
  15. Phil HordJul 6, 2012
  16. Marc BranchaudJul 6, 2012
  17. 5/6 Test that plain "git fetch" uses remote.default when on a detached HEAD.marcnarc@xiplink.com, Jul 5, 2012
  18. 6/6 Teach get_default_remote to respect remote.default.marcnarc@xiplink.com, Jul 5, 2012

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.