Don't configure remote "." to fetch everything to itself
commitad23603c3af77b47f65382ea22b30d1ecccaab6f
authorShawn O. Pearce <spearce@spearce.org>
Sun, 16 Sep 2007 06:32:11 +0000 (16 02:32 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 19 Sep 2007 10:22:31 +0000 (19 03:22 -0700)
treea999e0e7d560edfb5f55db90f4cd0892d2e4be81
parentb3abdd9d216c578383b66bb10b95edb3380640e7
Don't configure remote "." to fetch everything to itself

When we are talking about a remote URI of "." we are really talking
about *this* repository that we are fetching into or pushing out of.
There are no matching tracking branches for this repository; we
do not attempt to map a ref back to ourselves as this would either
create an infinite cycle (for example "fetch = +refs/*:refs/mine/*")
or it causes problems when we attempt to push back to ourselves.

So we really cannot setup a remote like this:

  [remote "."]
    url = .
    fetch = +refs/*:refs/*

In the case of `git push . B:T` to fast-forward branch T to B's
current commit git-send-pack will update branch T to B, assuming that
T is the remote tracking branch for B.  This update is performed
immediately before git-send-pack asks git-receive-pack to perform
the same update, and git-receive-pack then fails because T is not
where git-send-pack told it to expect T to be at.

In the case of `git fetch .` we really should do the same thing as
`git fetch $otherrepo`, that is load .git/FETCH_HEAD with the commit
of HEAD, so that `git pull .` will report "Already up-to-date".
We have always behaved like this before on this insane request and
we should at least continue to behave the same way.  With the above
(bad) remote configuration we were instead getting fetch errors
about funny refs, e.g. "refs/stash".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote.c