"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

Reply via email to