Daniel Barkalow [off-list ref] writes:
quoted
And I think it does today.
Hmm, and I guess URIs on the command line work the same way. How about
requiring a '/' somewhere in a repository argument in order to treat it as
a repository instead of a remote name? Then "../next-door-neighbour" would
work, "./gitcvs.git" would work (in the odd case where you actually have a
bare repository sitting in your working directory), but we'd avoid the
current default of pushing to a bare repository in "./origin/" if nothing
at all is configured.
When I wrote the message you are responding to, I thought this
was a regression from the current behaviour, which (IIRC--it's
getting late and I am tired to double check) essentially says if
the token is a name of the directory, the target repository is a
local one, but "we'd avoid..." part seems to suggest that you
actually did this deliberately as a fix to some problem in the
current behaviour. I am not however sure what it exactly is.
Could you care to elaborate the part after "we'd avoid..." to
clarify what the problem is, please?
On Thu, 10 May 2007, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
quoted
And I think it does today.
Hmm, and I guess URIs on the command line work the same way. How about
requiring a '/' somewhere in a repository argument in order to treat it as
a repository instead of a remote name? Then "../next-door-neighbour" would
work, "./gitcvs.git" would work (in the odd case where you actually have a
bare repository sitting in your working directory), but we'd avoid the
current default of pushing to a bare repository in "./origin/" if nothing
at all is configured.
When I wrote the message you are responding to, I thought this
was a regression from the current behaviour, which (IIRC--it's
getting late and I am tired to double check) essentially says if
the token is a name of the directory, the target repository is a
local one, but "we'd avoid..." part seems to suggest that you
actually did this deliberately as a fix to some problem in the
current behaviour. I am not however sure what it exactly is.
Could you care to elaborate the part after "we'd avoid..." to
clarify what the problem is, please?
The problem, in general, is that, if the remote name you specify (or
"origin" if you don't specify any) is not configured as a remote, it is
treated as a filename in the current directory for a local push. E.g.:
$ git init
$ git push
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
It's actually trying to push to ./origin/, which is totally nuts as a
default repository to push to. Similarly, if you typo an actual remote
name. Furthermore, builtin-push.c has an error message for the situation
where the repository specification is wrong, suggesting that there is
some invalid repository specification, but it isn't reachable. And it
carefully prevents remote names from starting with a '/', suggestion that
that is the distinguishing characteristic between directly-specified
repository URIs and configured remotes (which can't really be right, of
course).
I think the right answer is to say that configured remotes cannot contain
slashes, and directly-specified URIs must contain slashes, and it'll all
be clear.
-Daniel
*This .sig left intentionally blank*