Pulling from refs/remotes/ ?

Hi,

why can't I pull from a remote?  I can do 

  git log REMOTE-BRANCH
  git diff BRANCH REMOTE-BRANCH

etc. But pulling yields

 [hanwen@haring foobar]$ git pull . origin/nonrandr-setup
 error: no such remote ref refs/heads/origin/nonrandr-setup
 Fetch failure: .

also, "Fetch failure: .", what is that supposed to mean?

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

You are treating your local repository as if it is a remote repository somewhere else, namely, '.' (current repository).

Notice "git log" and "git diff" are LOCAL operations? "git pull" is "git fetch" which is a remote operation (i.e. it interacts with a remote repository) followed by "git merge" which is a local operation to merge in what was fetched or what you already have locally.

I think you would want:

	git merge REMOTE-BRANCH

e.g. "git merge origin/nonrandr-setup".

Junio C Hamano escreveu:

Yes, that works, thanks. Wouldn't it be more consistent with this reasoning to disallow

  git pull . LOCAL-BRANCH 

too?

I still think that "fetch failure" is a bad error message. What information does it convey?

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

I do not think so.

If somebody else (or yourself) did:

	$ git pull $dir LOCAL-BRANCH

(replace $dir with the `pwd` you would get in your repository), that would work. Why shouldn't it work for yourself?

Junio C Hamano escreveu:

 
Because

"You are treating your local repository as if it is a remote repository somewhere else, namely, '.' (current repository)."

that was the justification for not being able to pull in a remote branch. This justification (which I disagree with) applies to this case as well.

I understand that we don't want people committing to remotes, because fetches will then later fail, but other than that, why should there be limitations on using a remote?

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

Ah, so "forbidding a pull of local branch" was tongue-in-cheek comment, and what you really wanted was to allow pulling remote tracking branch with pull, either inside or outside of a repository, like...

	$ git pull $somebody_elses_repo remotes/origin/master

without having to say "remotes/"?

That one comes from a different design issue. refs/remotes/ hierarchy is local to your repository, and is not subject to remote operation.

My stance on this is that what I track as my upstream to maintain my repository is none of other people's business. I have remote tracking branches because I use them to track others; I do not necessarily have them with an intention to publish them.

You could pull from my remote tracking branches using the fuller refspec ("remotes/origin/master" in the example above) if you really wanted to, and ls-remote lets you take a peek at them, so the above "none of your business" is not in the sense of being secretive, but is to reduce clutter and to avoid potential confusion.

But this is an ancient design choice, and I am open to suggestions loosening it, as long as we are aware of implications.

One thing that comes to mind if we allow it is if a clone should have refs/remotes/origin/remotes/origin/* that keeps track of the remote that is being tracked by your origin.

I think it is insane to do so, but if somebody says "git pull somewhere-else origin/master", we would not know if he meant remotes/origin/master or remotes/origin/remotes/origin/master.

And the reason it is "insane" is the same as why we currently do not interpret "git pull $repo origin/master" as a request to pull from remotes/origin/master. It really is none of your business what kind of remote branches the other end is interacting with.

Junio C Hamano escreveu:

fair enough; my remaining gripe is that the error message is broken. My suggestion is to have

  git fetch . XXX

(and by extension: pull) print something like

  Will not fetch from self. 
  Do you mean "git merge XXX" or "git update-ref XXX" ? 

It may be an artificial restriction when compared to "git pull $dir XXX" but I think it helps the user better than "Fetch failure".