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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:09

Daniel Barkalow [off-list ref] writes:
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.

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

From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:43:09

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*
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help