patchclone: Remove constraint on --bare and --origin

This test has been present since long before clone was ported to C. Now there is no need for it, and since df61c88979 (clone: also configure url for bare clones, 2010-03-29) it's especially useful to allow both options.

Signed-off-by: Øystein Walle <oystwa@gmail.com>
---

A question on this constraint popped up on #git the other day. I investigated a bit and found no particular reason for its existence. All tests still pass (except the one removed here) and the behavior is as expected. I realize it might have gone under the radar for 11 years but it's still worth the noise to remove it, in my opinion.

I wanted to include a bit on the reasoning for the original check in the commit message but I couldn't find it.

 builtin/clone.c          | 3 ---
 t/t5606-clone-options.sh | 8 --------
 2 files changed, 11 deletions(-)

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

I suspect that this originally was because "git clone --bare" does not use any remote-tracking branch (i.e. no refs/remotes/origin/*) and the only expected way to update a "git clone --bare" repository was to run "git fetch --mirror [--prune]", so there was no need to make the nickname "origin" to be configurable.

I do not offhand know what other features in "git clone --bare" that were added since then affect the resulting repository so that the name "origin" it leaves there (perhaps in its configuration, if not names in ref hierarchy) is visible to the end user and deserves to be customizable.

In short, I think the "don't use --origin in a bare repository" was not because "doing so will break X and Y", but because "doing so does not make any practical difference". So I am OK to lift this check. It is a small enough change that is easy to revert if there were some valid reasons we failed to consider.

Thanks.

On Sun, Aug 01 2021, Øystein Walle wrote:

Aside from working in Junio's reply as a summary of the original justification in the commit message for a v2...

This just removes the only test, if it's "especially useful" to allow both options let's replace this with a test that shows and tests for those use-cases.

The constraint on passing both these options simultaneously has been present since long before clone was ported to C. At the time no configuration referencing the remote repository was written at all in bare clones.

Since df61c88979 (clone: also configure url for bare clones, 2010-03-29) the remote repository is mentioned in the configuration file also for bare repos, so it makes sense to allow the user to rename it if they wish.

Signed-off-by: Øystein Walle <oystwa@gmail.com>
---

Hi Junio and Ævar,

I investigated a bit more and updated the commit message accordingly. Instead of just removing the test I have replaced it with one that checks that the behavior is as intended.

Ævar, I was a bit melodramatic when I wrote "especially useful". I have toned the commit message down a bit :-) In truth, I don't personally have a use-case for this (I did reach out to the person who asked about it in #git but did't get a reply) and have no problems with seeing this patch ultimately rejected. It's just a result of me seeing it asked about and getting an itch from it. But in my humble opinion this is now an "artificial" constraint (for lack of a better term) and should be removed on the grounds that there is no reason for it to be there in the first place.

Thanks, Øsse

 builtin/clone.c          |  3 ---
 t/t5606-clone-options.sh | 10 +++++-----
 2 files changed, 5 insertions(+), 8 deletions(-)

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

Sounds sensible.

Yup, that is exactly my thought when I responded to your v1.

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". Instead of "usually the thing is called 'origin', so let's make sure it does not exist", we may want to say "there is only one remote and it is called somewhere because that is how we named it", i.e.

	git -C clone-bare config --name-only \
		--get-regexp "remote\..*\.url" >actual &&
	echo remote.somewhere.url >expect &&
	test_cmp actual expect

But stepping back a bit, I think this shows another reason why use of '--origin' with '--bare' as-is may not be so pleasant to use.

In a repository _with_ working tree, this lack of "what is 'origin' called in this repository?" is not a problem because you'd get these after cloning:

    [remote "somewhere"]
	url = ...
	fetch = ...
    [branch "master"]
	remote = "somewhere"
	merge = refs/heads/master

You can say "git fetch" or "git pull" without the remote name and we will know which remote to interact with, because our branch knows which remote to fetch from.

In a bare repository, however, you only get this:

    [remote "somewhere"]
	url = ...

I do not think "git fetch" in such a repository knows that it needs to fetch from 'somewhere', even whe it is the only remote repository available to us.

We may need a bit _more_ work (e.g. leave an optional configuration remote.originName = "somewhere" when "--bare --origin somewhere" is used, and teach "git fetch" to pay attention to it, instead of assuming 'origin') before "--bare --origin somewhere" becomes truly usable. And I suspect that "git fetch" is not the only one that needs such "fix".

Hi again,

Thanks for accepting the patch.

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.

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 :-) 

Both usages appear in the wild and are even mixed sometimes, but in my experience it's not a big deal; it's usually obvious from context. I think the second usage is the common one, but the name is so common that it leads to the first. Is this something we'd like to tackle? If so, it just occured to me that it certainly doesn't help that the switch to change the name referring to the repo that was cloned from "origin" to something else is "--origin".

Changing git fetch to fall back to a remote not named "origin" if that is the only one configured makes perfect sense to me. (I am skeptical about remotes.originName since that favors the first usage outlined above.)

I have cc'ed the origin (pun overtly intended) of this patch and discussion for their take on it.

This seems like like a better test than the one I wrote.

By the way, I noticed you already fixed my mistake with the repo name. Thanks for that. I sent this as a v2, but as you can imagine I did it in two steps in real life. First I removed the test then later I wrote a new one, and in between I rebased my changes. In the mean time new tests were added. I noticed they failed, but I didn't realize that was my fault.

Øsse

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

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".

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:

I'm not sure why this matters (not saying it doesn't).
 

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.
 

 
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 Neuhauser <rn+git@sigpipe.cz> writes:

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.

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:

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.

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.

how would that help the people who yearn for clone --bare --origin but wouldn't use it if it meant fetch with explicit remotes?

i agree.
 

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:

when does this matter?

---

looking over the earlier emails, i'd like to reiterate one thing:

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

Junio C Hamano <gitster@pobox.com> writes:

So, let's illustrate one of the things that is needed after the good first step to allow --bare --origin=yourfavouritename used together.

There may be other things that needs fixing, of course, but we need to start from somewhere.

---- >8 -------- >8 -------- >8 -------- >8 -------- >8 -------- >8 ----
Subject: [PATCH] remote: fall back on the sole remote when unspecified

Historically, we used hardcoded "origin" as the fallback default for commands that take a remote (e.g. "git fetch") when the user did not tell us otherwise. Since the "--origin=name" option was taught to "git clone", however, we may not have a remote whose name is "origin" at all.

Which means that the name given to "git clone --origin" does not truly replace the hardcoded "origin". An example of such limitation is that "git fetch" (no other parameters) would fetch happily from the "origin" repository, but in a repository cloned with the custom name using "--origin=name", "git fetch" would not fetch from anywhere and instead fail.

We can fix this by noticing that the repository has one and only one remote defined, and use that as a replacement for the hardcoded "origin".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

This matters for automation for those who want to use --origin option. Imagine you have multiple bare clones and you wanted to use custom names for 'origin'. And you want a cron job that goes over these repositories and run "git fetch" from their upstream before you come in for work, so that these bare clones can be used as close-by mirrors of their upstream projects.

Unfortunately, that would not work. If these repositories use their own nicknames for their upstream that are not "origin",

	for repo in a b c
	do
		git -C $repo fetch
	done

would just fail. Of course, you can somehow out-of-band know the origin's name for each repo, e.g.

	for repoorigin in a:xyzzy b:frotz c:nitfol
	do
		repo=${repoorigin%:*}
                origin=${repoorigin#*:}
		git -C $repo fetch $origin
	done

but that is solving a problem that arises only because we are not treating the name given to "git clone --origin=name" as a true replacement for the default "origin".

 remote.c             | 10 +++++++++-
 t/t5512-ls-remote.sh | 10 ++++++++--
 2 files changed, 17 insertions(+), 3 deletions(-)

# gitster@pobox.com / 2021-08-07 15:08:02 -0700:

hey, i'm all for all this pre-existing lossage getting fixed if you can do it. all i'm saying is that since this combination of options wasn't possible before there won't be any pre-existing uses of git suddenly breaking.

imagine that you wanted to use git clone --bare --origin with
any git version released so far.  this is not snark, i'm pointing
out that git git has a history of things not working where one
would expect them to.
 

  for repo in a b c; do
    git -C $repo fetch --all # or git -C remote update
  done

all it takes to mitigate this is to point this out in the release
notes and man page.  what you sketched out above is analogous to my
initial encounter with git clone --bare --origin not working:
where were you when the half-assed implementation was landing?  :)
why was there no one to champion for people who'd want to use those
two together? :)) (j/k)
 

even if i accept the premise that git fetch --all can't be used and the explicit name is necessary, isn't that magical out-of-band wand called git-config?

  origin=$(
    git config --file $repo \
    --name-only --get-regexp \
    '^remote\.[^.]*.url' |
    sed -E 's/^remote\.([^.]+).url$/\1/'
  )
  git -C $repo fetch $origin
 
i'm not skilled enough in git-config to simplify that.

i think it'd be prudent to pause this thread for now because it's only distracting you from fixing the --origin fallout, and as long as you talk about how it *should* be while i bring up available workarounds, it's just noise.

and i'm really grateful that you're tying the loose ends, as long
as this whole thing doesn't fizzle out on account of being too much,
and the partial improvement doesn't get swept with it!
 
i think i said in earlier that i'm a big fan of stripping "origin"
of its special standing.  huge kudos if you can see this through.

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

This breaks a later step that creates clone-bare as this used to use clone-bare-o and the name was available.

Using clone-bare-o as it used to would probably be the easiest fix.