"Philip Oakley" <philipoak...@iee.org> writes:
> So we can have a branch whose remote is '.'
> _and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
"git fetch" while on "mywork" branch with this:
[branch "mywork"]
remote = git://git.k.org/pub/scm/git/git.git
merge = refs/heads/master
without having any named remote whose remote.$name.url is set to
that URL may happen to work but it is by accident as far as I know.
As you do not copy to any remote tracking branches, @{u} would not
work, so it is not something useful. But on the other hand
[branch "mywork"]
remote = .
merge = refs/heads/master
works _as if_ you have
[remote "."]
url = "."
;; no fetch refspec like +refs/heads/*:refs/heads/*
;; no push refspec like +refs/heads/*:refs/heads/*
so in that sense, you _could_ think of branch.$name.remote as a
(generic) URL or a name of a (special) remote, but it is easier to
think about it as the latter.
And remote.$name.url = "." for any name, e.g.
[remote "here"]
url = "."
is a special case of local repository that is named with a relative
filesystem path.
> Can there be a clash with a named remote that is actually '.', where
> the push/fetch is actually a no-op?
Nobody sane would do it in the first place, so...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
