Re: Question: What is the best practice regarding remote names

Yes.  But you can also specify git clone --origin upstream <url>
which is confusing as well.  --origin is the name of a command line option
with a default value "origin"

All the confusion resolves when you understand that the term, when used in
Git, has more than one meaning depending on the context.
- name of an option
- name of a remote that may or may not point to a personal fork.
- name of a remote a fork because that's what I cloned without specifying a
remote name
- name of a remote to an official repository because it's my very own app
and I can commit to it anytime I want
- name of a remote to an official repository that does not belong to me and
to which I have no commit rights.
- where Spiderman came from. (oh wait. that's an origin *story*)
;-)

-Pat
 - Likes Git. And puns.

On Tue, Jun 23, 2026 at 1:46 PM Frederic T. <[email protected]> wrote:

> Actually, if you run git clone with just an URL, origin simply points to
> whichever URL you told it to clone from - git cannot know if that's the
> upstream or your fork.
>
> Am Di., 23. Juni 2026 um 19:41 Uhr schrieb Patrick Callahan <
> [email protected]>:
>
>> Thanks Frederic,
>>
>> Origin pointing to forks is what I thought.  I just wanted to confirm
>> it.
>>
>> While you are correct that remote names do not really matter when running
>> git commands, I'd suggest they do matter in communication among project
>> participants.
>>
>> So origin points to the user's fork if you are developing, but if you run
>> the clone command, origin points to the remote the clone came from by
>> default.  This is only the start of where things git confusing.  The
>> confusion is furthered by the simplification of defaults applied in fetch,
>> pull, push, and branch commands.  The possible source of confusion may not
>> matter to those who follow a strict discipline in their use of git, whether
>> enforced by their project or by long and daily practice.  Those of us to
>> which those constraints do not apply have a different problem:  How long do
>> we want to take to master git.  Personally, I don't need to master git. I
>> just need to know how to use it effectively.  So I've adopted a strategy
>> that git command defaults do not apply and I specify things like remotes
>> and branch names explicitly in scripts that I've tested and I know produce
>> a desired outcome.  That doesn't mean I have nothing still to learn about
>> using git.  I just means that for the everyday work, I've thought things
>> through, tested, and what I know works serves its purpose.
>>
>> That origin should point to a fork may come as a surprise when someone
>> graduates from using download_and_compile.sh script to active development.
>> The script just clones from the official repositories as origin.  If
>> you've been using the script for years, you will be forgiven if you conclude
>> origin kind of means "official repos".
>>
>> New developers unfamiliar with git usage might be confused, as I was, by
>> the term "origin", having associated it with the official repositories by
>> "default" for a period of years.
>>
>> -Pat
>>
>> origin [email protected]:callahanp/flightgear.git (fetch)
>> origin [email protected]:callahanp/flightgear.git (push)
>> upstream https://gitlab.com/flightgear/flightgear.git (fetch)
>> upstream no-push (push)
>>
>> _______________________________________________
>> Flightgear-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel