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@xxxxxxxxxxx>
---
This fixes the "push to yourself" breakage I mentioned yesterday.
remote.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/remote.c b/remote.c
index df91b2f..73a34c9 100644
--- a/remote.c
+++ b/remote.c
@@ -356,10 +356,6 @@ struct remote *remote_get(const char *name)
add_uri(ret, name);
if (!ret->uri)
return NULL;
- if (!strcmp(name, ".")) {
- // we always fetch "refs/*:refs/*", which is trivial
- add_fetch_refspec(ret, "refs/*:refs/*");
- }
ret->fetch = parse_ref_spec(ret->fetch_refspec_nr, ret->fetch_refspec);
ret->push = parse_ref_spec(ret->push_refspec_nr, ret->push_refspec);
return ret;
--
1.5.3.1.1000.g7319b
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
