Øystein Walle [off-list ref] writes:
Hi again,
Thanks for accepting the patch.
quoted
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".
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.
Hello,
i'm "the user" in this story. Muchas gracias to osse for turning
my bickering into a patch.
A little background. I use --origin a lot (or git remmote rename
afterwards), because origin carries no information about the remote
repository, and I could have cloned any of those. The URL I used
in `git clone` has little to do with which remotes I'll want to
pull from and which I'll want to push to. "origin" is suspicious
and I'm used to giving my remotes names that mean something to me.
My need for git clone --bare --origin surfaced when I was writing
a tool for versioning dotfiles (don't we all have one). It has to
be able to work with pre-existing files in the home dir:
$ git dirs clone $url x
# git-dir is $PWD/.git-dirs/repo.d/x
# work-tree is $PWD
I used git clone --bare / git config core.bare false /
git config core.worktree ... and hit the error message when I tried
to add support for --origin.
# gitster@pobox.com / 2021-08-04 10:06:31 -0700:
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".
I'm not sure why this matters (not saying it doesn't).
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.
Isn't that the case in non-bare repositories as well?
BTW I don't like special cases but realize that the "origin" ship has
sailed long ago.
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.
Can't they just continue doing what they've been doing so far,
that is leave it at "origin"? I'm not sure this would be my concern
as a user of this feature.
--
roman
Roman Neuhauser [off-list ref] writes:
quoted
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.
Isn't that the case in non-bare repositories as well?
You have branches that are checked out. The first branch that you'd
presumably be using as the primary (traditionally called 'master')
knows that the nickname used to call the remote it integrates with
as the value of branch.master.remote
In a bare repository, there is no such clue.
Can't they just continue doing what they've been doing so far,
that is leave it at "origin"? I'm not sure this would be my concern
as a user of this feature.
That answer can be thrown back at you. You can leave it at "origin"
when using "--bare" ;-).
The posted patch is a good first step to allow both options to be
used at the same time. Without the first step, these two options
cannot coexist.
But I am also saying that the first step alone is an inadequate
solution that goes only halfway. If you can get yourfavouritename,
while others cannot use their favourite names, that is not a
satisfying solution.
# gitster@pobox.com / 2021-08-06 15:13:35 -0700:
Roman Neuhauser [off-list ref] writes:
quoted
quoted
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.
Isn't that the case in non-bare repositories as well?
You have branches that are checked out. The first branch that you'd
presumably be using as the primary (traditionally called 'master')
knows that the nickname used to call the remote it integrates with
as the value of branch.master.remote
aha, i see that as a special (heh) case, an exception. :)
i spend most of my time on branches with no upstram. sure, they're
extensions of master and such, but they have no upstream themselves.
and since there's no "origin" remote in my repos:
git checkout -b fix-this-or-that master
# tadaa, git fetch does nothing[1]
git fetch losing the hardcoded "origin" in favor of a configurable
value would be an improvement, yes.
quoted
Can't they just continue doing what they've been doing so far,
that is leave it at "origin"? I'm not sure this would be my concern
as a user of this feature.
hm, that last sentence came out wrong. i meant to say that as a user
of this feature, i would not mind having to provide and explicit remote.
That answer can be thrown back at you. You can leave it at "origin"
when using "--bare" ;-).
how would that help the people who yearn for clone --bare --origin
but wouldn't use it if it meant fetch with explicit remotes?
The posted patch is a good first step to allow both options to be
used at the same time. Without the first step, these two options
cannot coexist.
i agree.
But I am also saying that the first step alone is an inadequate
solution that goes only halfway. If you can get yourfavouritename,
while others cannot use their favourite names, that is not a
satisfying solution.
i don't see how the patch in its current form prevents anyone from
naming --origin whatever they want (within the accepted syntax).
---
i think a step back is in order. git fetch --all would work,
git remote update would work. if the issue is the imaginary
guy's ability to update the bare repo without peeking inside
config, either of these commands has him covered.
if the goal is to enable git fetch w/o --all or any other remote
specification then i'd say remote.fetchDefault would be a nice
mirror to remote.pushDefault. this glaring asymmetry would go away:
If no remote is configured, or if you are not on any branch,
it defaults to origin for fetching and remote.pushDefault
for pushing.
if you want the repo to remember where it was cloned from,
then again, remote.fetchDefault can fill that role. obviously
mutable, but any setting would be, and i just don't see a problem
with that.
coming back to a question that fell below the radar:
# gitster@pobox.com / 2021-08-04 10:06:31 -0700:
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".
when does this matter?
---
looking over the earlier emails, i'd like to reiterate one thing:
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.
i can't speak for others, but with me, this assumption is flat out
wrong. half my "working copies" get cloned from upstream sources
and i add a remote to publish my changes from later, while the other
half happens the other way around. the urls given to git clone
don't mean... much[2].
finally, this notion that --origin in a regular clone works just like
"origin" is generally false. relevant to bare repos, if you don't
have any branch checked out, it goes to "origin". iow if symmetry
between regular and bare clones is the goal, then mission accomplished,
they already behave the same.
[1] not only does it do nothing, it does it without a beep, which,
aside from the runtime, looks just like a successful fetch from
a remote i'm up-to-date with.
[2] https://www.youtube.com/watch?v=WO2q1iQX2UA
--
roman; btw, git-pull is backwards