Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

["Philip Oakley" <philipoakley@iee.org>]

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Monday, May 20, 2013 6:55 PM
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> --- a/Documentation/gitcli.txt
>>> +++ b/Documentation/gitcli.txt
>>> @@ -59,6 +59,10 @@ working tree.  After running `git add hello.c; rm 
>>> hello.c`, you will _not_
>>>  see `hello.c` in your working tree with the former, but with the 
>>> latter
>>>  you will.
>>>
>>> +Just as, by convention, the filesystem '.' refers to the current 
>>> directory,
>>> +using a '.' (period) as a repository name in Git (a dot-repository) 
>>> refers
>>> +to your local repository.
>>
>> Good idea, but I fear that no one would find it there.
>
> Also I think it would be better without ", by convention,".  If you
> say '.' == current directory is "a convention", you have to start
> saying that "by convention", "hello.c" refers to the file in the
> current directory of that name, which may be technically correct but
> make the phrase "by convention" meaningless.  A dot "."  is *the*
> name for the current directory, just like "hello.c" is the name for
> that file.

The part I had previously needed clearing up was if the '.' was in some 
way expanded by the shell, or whether the file system commands 
interpreted it by themselves for that specific purpose. So in this case 
Git sees the single character and has to decide what to do with it.

>
>    Just like '.' refers to the current directory in the filesystem, 
> '.'
>    refers to the current repository.
>
> would be sufficient.
>
>> Would it make sense to put this in Documentation/urls.txt (aka the
>> "GIT URLS" section of git-fetch(1) and git-clone(1)), where other URL
>> schemes are documented?
>
> Yes, the '.' described above is a special case of giving a
> repository URL as a relative-path on the filesystem.

So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'

Hence we/one/I could declare a remote called 'home' whose URL is '.'
(with my 'away' remote on Github - just thinking aloud of the upstream / 
downstream / across-stream discussions!)

Can there be a clash with a named remote that is actually '.', where the 
push/fetch is actually a no-op?

Philip