Re: Pulling from refs/remotes/ ?

Han-Wen Nienhuys [off-list ref] writes:

quoted

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?

 
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.

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.

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?

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:

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.

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

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen