Re: [PATCH v2] clone: Allow combining --bare and --origin

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 4, 2021, 17:06 UTC
Message-ID: <xmqqbl6dqgvc.fsf@gitster.g>
In-Reply-To: <20210804133010.25855-1-oystwa@gmail.com>

Øystein Walle <oystwa@gmail.com> writes:

Show 12 quoted lines

> Hi again,
>
> Thanks for accepting the patch.
>
>> It is somewhat unfortunate that we do not say what the name of the
>> "origin" is anywhere in the resulting configuration file.  The only
>> way to tell that "--origin somewhere" was used is to notice that there
>> is only one remote and its name is "somewhere".
>
> This reads as self-contradictory to me. The word "origin" is nowhere in
> the configuration file, that's true. But that's because the user chose
> it to be that way, and the name the user chose is in the there.

In other words, if there were two remotes in the configuration file, you cannot tell which one was given to --origin when you made the repository with "git clone".

Show 10 quoted lines

> The reason I see it as self-contradictory is that I see two different
> usages of the word "origin" in your email:
>
>  1. A *term* meaning the repository that was cloned (e.g. 'name of the
>  "origin"', remote.originName)
>
>  2. The *name* of a remote ('there is only one remote and its name is
>  [not "origin"]')
>
> Seems you are aware since you write it in quotes :-)

May be but #1 is not all that interesting.

I meant the only one thing. The user told Git that 'somewhere' is the word, not 'origin' that is used by those who use the default configuration, will be used to refer to the remote the repository was cloned from. In the first paragraph you quoted, I was referring to the fact that the knowledge will be lost once you did "git remote add elsewhere".

We cannot tell between 'somewhere' and 'elsewhere', which one is what those who use the default configuration would refer to 'origin'---presumably, 'somewhere' being the --origin's argument when "git clone" was run, has some significance over 'elsewhere' in the user's mind, even after the latter is added to the repository.

But we'd end up treating them the same. And something like remote.originName would help that. Otherwise, we'd end up sending this message:

    Even if we give "--bare --origin yourfavouritename" to you now,
    unlike how 'origin' is treated in the default case, in the
    resulting repository, 'yourfavouritename' is not special at all.

Some people may want to treat yourfavouritename is not special at all, while some people may want to treat yourfavouritename truly as a replacement for 'origin' that is the default. The message we would be sending is that we'd ignore the latter folks.