From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Monday, May 20, 2013 6:55 PM
Jonathan Nieder <jrnieder@xxxxxxxxx> 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
--
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