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

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

Daniel Barkalow [off-list ref] writes:

quoted

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

quoted

This seems to break t9400, with "fatal: bad repository 'gitcvs.git",
upon "git push".

: gitster t/db/remote; sh t9400-git-cvsserver-server.sh -i -v
* expecting success: cvs -Q co -d cvswork master &&
   test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"
cvs checkout: Updating cvswork
U cvswork/empty
*   ok 1: basic checkout

* expecting success: echo testfile1 >testfile1 &&
   git add testfile1 &&
   git commit -q -m "Add testfile1" &&
   git push gitcvs.git >/dev/null &&

The man page doesn't think this is valid, since it only claims absolute 
paths to work for local repositories.

Does it?  I suspect we need to fix the manpage then, as it is
fairly common to do 

	$ git fetch ../next-door-neighbour

and expect the opposite to work as well.

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.

	-Daniel
*This .sig left intentionally blank*