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