Does `git` name only as "origin" any remote upon cloning?

Does Git only use the remote name "origin" for a repository which was created by cloning?

For example, say I create a repository, placed it on a remote, 开发者_Go百科and try to clone it again into the same directory, which one would Git name origin?

2010: origin is the default name used by git clone, but you can use any other name when cloning:

--origin <name>
-o <name>

Instead of using the remote name origin to keep track of the upstream repository, use <name>.

If you don't, any time you clone a repo, that remote repo will be referenced by the default name origin.

With Git 2.30 (Q1 2021, 11 years later), you now have the option clone.defaultRemoteName.

If origin doesn't fit you, you can always rename it to a more appropriate name:

git remote rename <old> <new>

See description of git remote.

With Git 2.30 (Q1 2021), "git clone"^(man) learned clone.defaultremotename configuration variable to customize what nickname to use to call the remote the repository was cloned from.

See commit de9ed3e, commit 75ca390, commit ebe7e28, commit f2c6fda, commit 444825c, commit 552955e (01 Oct 2020), and commit 349cff7 (29 Sep 2020) by Sean Barag (sjbarag).
^{(Merged by Junio C Hamano -- gitster -- in commit 40696c6, 27 Oct 2020)}

clone: allow configurable default for -o/--origin

^{Helped-by: Junio C Hamano
Helped-by: Johannes Schindelin
Helped-by: Derrick Stolee
Helped-by: Andrei Rybak
Signed-off-by: Sean Barag}

While the default remote name of "origin" can be changed at clone-time with git clone^(man)'s --origin option, it was previously not possible to specify a default value for the name of that remote.
Add support for a new clone.defaultRemoteName config, with the newly-created remote name resolved in priority order:

1. (Highest priority) A remote name passed directly to git clone -o^(man)
2. A clone.defaultRemoteName=new_name in config git clone -c^(man)
3. A clone.defaultRemoteName value set in /path/to/template/config, where --template=/path/to/template is provided
4. A clone.defaultRemoteName value set in a non-template config file
5. The default value of origin

git config now includes in its man page:

clone.defaultRemoteName

The name of the remote to create when cloning a repository.
Defaults to origin, and can be overridden by passing the --origin command-line option to git clone.

git clone now includes in its man page:

Instead of using the remote name origin to keep track of the upstream repository, use <name>.
Overrides clone.defaultRemoteName from the config.

Warning:

git -c core.bare=false clone --bare ...^(man) would have segfaulted, which has been corrected with Git 2.32 (Q2 2021).

See commit 7555567 (10 Mar 2021) by brian m. carlson (bk2204).
^{(Merged by Junio C Hamano -- gitster -- in commit 3099d4f, 22 Mar 2021)}

builtin/init-db: handle bare clones when core.bare set to false

^{Reported-by: Joseph Vusich
Signed-off-by: brian m. carlson}

In 552955e ("clone: use more conventional config/option layering", 2020-10-01, Git v2.30.0-rc0 -- merge listed in batch #1), clone learned to read configuration options earlier in its execution, before creating the new repository.

However, that led to a problem: if the core.bare setting is set to false in the global config, cloning a bare repository segfaults.

This happens because the repository is falsely thought to be non-bare, but clone has set the work tree to NULL, which is then dereferenced.

The code to initialize the repository already considers the fact that a user might want to override the --bare option for git init^(man), but it doesn't take into account clone, which uses a different option.
Let's just check that the work tree is not NULL, since that's how clone indicates that the repository is bare.
This is also the case for git init, so we won't be regressing that case.