From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 20 May 2013 22:22:46 GMT
Subject: Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery
Message-ID: <7v1u91uw95.fsf@alter.siamese.dyndns.org>
In-Reply-To: <BDA138F1A58247F4A4940B3436A94485@PhilipOakley>

"Philip Oakley" <philipoakley@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...