Re: [PATCH 1/3] Move remote parsing into a library file out of builtin-push.

[Daniel Barkalow <barkalow@iabervon.org>]

On Thu, 10 May 2007, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > On Thu, 10 May 2007, Junio C Hamano wrote:
> >
> >> Daniel Barkalow <barkalow@iabervon.org> 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
> 
> Ahh.  You were trying to give it a better error message.
> 
> I think I lied in the previous message.  I said we try to see if
> it is a local directory name before using that name, but we do
> not do it, and leave the error detection to the lower level on
> the other side (push spawns send-pack which in turn spawns
> receive-pack) instead.
> 
> Perhaps an alternative is to see if the name is configured as a
> remote (if so, we obviously use it), and if not do stat() to see
> if it is a directory (if so, use it as a local repository).
> Then we do not have to impose new restriction of slash at all,
> although it might complicate the code a bit more.

The problem I see with allowing paths without slashes is if you've got a 
subproject with a name similar to a remote name, and type the wrong one 
(particularly due to tab-completion), or if you've got a remote name you 
use in other projects that matches a subproject in a project where you 
aren't using that remote name. I think that a repository in your working 
directory is unlikely to be something you actually want to push to or 
fetch from (and if this is actually what you want, ./directory is the 
usual unixy thing for saying, no really, I want a relative path in the 
current directory, and would work here; and it would be good practice 
anyway, so that you don't get tripped up if you create a remote 
configuration with that name later). Obviously, ../something has a slash; 
it should also take ':' to mean a URI (which I didn't realize last night), 
so that "person@machine:directory.git" is a URI.

I think, as a general rule, that it would be cleanest to distinguish 
lexically between repository names that indicate configured remotes and 
repository names that are URIs, particularly if we only break usage that 
people only do for writing git regression tests.

	-Daniel
*This .sig left intentionally blank*