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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: May 10, 2007, 08:04 UTC
Message-ID: <Pine.LNX.4.64.0705100355560.18541@iabervon.org>
In-Reply-To: <7vmz0dktdf.fsf@assigned-by-dhcp.cox.net>

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

Show 30 quoted lines

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