On Thu, 10 May 2007, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > >> 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* - 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
