From: Jan Wielemaker <hidden> Date: 2016-06-15 22:43:38
Hi Dscho,
Thanks for the comments. I'll keep in on the list, just in case there is
someone else with a brilliant idea.
On Thursday 04 October 2007 00:14, you wrote:
Hi,
On Wed, 3 Oct 2007, Jan Wielemaker wrote:
quoted
On Wednesday 03 October 2007 20:55, you wrote:
quoted
On Wed, 3 Oct 2007, Jan Wielemaker wrote:
quoted
On Wednesday 03 October 2007 18:11, Johannes Schindelin wrote:
quoted
Hi,
On Wed, 3 Oct 2007, Jan Wielemaker wrote:
quoted
2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the
current HEAD of module
AFAIR we do not allow committing via pserver protocol. Might that
be your problem?
Thanks, but no. I'm using CVS over SSH. I've been looking around in
git-cvsserver source a bit and it aborts quite quickly if you try a
commit through pserver. I get a bit further, but it cannot find the
HEAD revision for some reason and (from later message), if I try to
checkout master instead of HEAD it finds the revision but I get a
hash mismatch.
Okay, another stab: is your HEAD detached?
I'm a humble git beginner, though I think *my* head is still attached
:-) In any case, we are talking a fresh repository and I can perfectly
well clone it as well as pull and push from the clone using GIT
commands. How do I tell whether the HEAD is detached?
You can tell by looking into .git/HEAD (on the side that runs the server).
If it is a 40-character hex string, the HEAD is detached. Otherwise, it
should contain something like "refs/heads/master".
Its the latter, so my HEAD is still attached. I hope I understand this
correctly, but browsing the docs suggests a detached head is not really
a normal situation, so I'm fine. Right?
Other reasons for the failure could be:
- your user does not have write access
Definitely ok (also put an strace -o logfile git-cvsserver "$@" script
around it. No alarming permission or non-existence errors).
- the uid under which git-cvsserver runs has no write access
See above
- you found an error that only triggers with your repo
Great! Its so damn simple and and tried with three repos created
in three different ways, that I'm either extremely unlucky or many
more should be faced with this or nobody uses git-cvsserver.
I'm hoping for a command-by-command sequence that gets me a definitely
fine repository, so at least I can see it running correctly once. Then
maybe I can analyse traces in detail to see where they differ and what
is wrong. Somebody?
Thanks --- Jan
From: Jan Wielemaker <hidden> Date: 2016-06-15 22:43:38
quoted
Other reasons for the failure could be:
- your user does not have write access
Definitely ok (also put an strace -o logfile git-cvsserver "$@" script
around it. No alarming permission or non-existence errors).
quoted
- the uid under which git-cvsserver runs has no write access
See above
quoted
- you found an error that only triggers with your repo
Great! Its so damn simple and and tried with three repos created
in three different ways, that I'm either extremely unlucky or many
more should be faced with this or nobody uses git-cvsserver.
Finally getting at what is either a bug in git-show-ref or
git-cvsserver. I retried the whole lot using git-1.5.3.4:
<create initial repository>
% Created /home/jan/tmp/test/, added a file README with some text
% git-init
% git-add .
% git-commit
<create bare one for sharing>
% cd /home/git
% mkdir test.git
% cd test.git
% git --bare init --shared
% git --bare fetch /home/jan/tmp/test master:master
% git-config gitcvs.enabled 1
% git-config gitcvs.logfile `pwd`/cvs.log
% touch cvs.log
% chmod g+w cvs.log
% chgrp -R eculture .
<checkout>
% export CVS_SERVER=git-cvsserver
% cvs -d:ext:jan@localhost:/home/git/test.git co HEAD
% cd HEAD
% emacs README
% cvs commit -m test
cvs [commit aborted]: end of file from server (consult above messages if
any)
Same user, so we should not have permission rights. Indeed, the trouble
is here: git-cvsserver, near line 1203:
my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
$state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
indeed gives no output. git show-ref -s refs/heads/master works just
fine. HEAD in the repo says:
gollem (test.git) 2_> cat HEAD
ref: refs/heads/master
I guess this link must be picked up by either git-cvsserver or
git-show-ref. Right? Anyway, if I add the line marked + to
git-cvsserver, cvs commit and cvs add operations appear to work (I
assume only if I work on the HEAD).
$ENV{GIT_INDEX_FILE} = $file_index;
+ $state->{module} = "master";
# Remember where the head was at the beginning.
Thanks for the comments. Really worrying is that such a big flaw can be
in stable git and remain their for at least 3 patch levels unnoticed.
Will someone take care of this and fix it properly in the right place
instead of this dirty hack?
Thanks --- Jan
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:38
Hi,
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
Indeed, the trouble is here: git-cvsserver, near line 1203:
my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
$state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
indeed gives no output. git show-ref -s refs/heads/master works just
fine.
Ah! Did you do "CVSROOT=:ext:blablub cvs co HEAD"?
You should "co master". The branches in git are the modules in cvs.
HEAD is too volatile, you cannot make a proper module from it (imagine for
example "git checkout next" where "next" is a branch, followed by "git
checkout html", where "html" is another branch).
Ciao,
Dscho
From: Jan Wielemaker <hidden> Date: 2016-06-15 22:43:38
Hi Dscho,
On Thursday 04 October 2007 14:56, Johannes Schindelin wrote:
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
quoted
Indeed, the trouble is here: git-cvsserver, near line 1203:
my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
$state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
indeed gives no output. git show-ref -s refs/heads/master works just
fine.
Ah! Did you do "CVSROOT=:ext:blablub cvs co HEAD"?
Yip ...
You should "co master". The branches in git are the modules in cvs.
HEAD is too volatile, you cannot make a proper module from it (imagine for
example "git checkout next" where "next" is a branch, followed by "git
checkout html", where "html" is another branch).
Ok. Pretty sure I got literal HEAD from one of the examples somewhere ...
Or, I've been blind all along. Anyway, the maintainer may consider giving
an error when trying to access HEAD as a module. Would have saved about
2 days work and its unlikely I'm the last victim :-(
Part of the two days is that during all the things I tried somehow
messed up with master too, so the one time I tried that it failed as
well :-(
Anyway, case closed. On with the testing ...
Thanks --- Jan
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:38
It does not make sense to check out tags or "HEAD".
Noticed by Jan Wielemaker.
---
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
> On Thursday 04 October 2007 14:56, Johannes Schindelin wrote:
>
> > Ah! Did you do "CVSROOT=:ext:blablub cvs co HEAD"?
>
> Yip ...
>
> > You should "co master". The branches in git are the modules
> > in cvs.
> >
> > HEAD is too volatile, you cannot make a proper module from it
> > (imagine for example "git checkout next" where "next" is a
> > branch, followed by "git checkout html", where "html" is
> > another branch).
>
> Ok. Pretty sure I got literal HEAD from one of the examples
> somewhere ... Or, I've been blind all along. Anyway, the
> maintainer may consider giving an error when trying to access
> HEAD as a module. Would have saved about 2 days work and its
> unlikely I'm the last victim :-(
This patch is completely untested. Could you try it, please?
If it works:
Signed-off-by: Johannes Schindelin [off-list ref]
Cc'ed Frank, who is de-facto maintainer (according to shortlog)
and Martin, who started it all IIRC.
git-cvsserver.perl | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
@@ -770,6 +770,14 @@ sub req_co$log->debug("req_co : ".(defined($data)?$data:"[NULL]"));+if(system("git","rev-parse","--verify","refs/heads/$module")!=0)+{+$log->warn("Checkout failed: $module is not a branch");+print"error 1 Checkout failed: $module is not a branch\n";+chdir"/";+exit;+}+$log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");$ENV{GIT_DIR}=$state->{CVSROOT}."/";
@@ -770,6 +770,14 @@ sub req_co$log->debug("req_co : ".(defined($data)?$data:"[NULL]"));+if(system("git","rev-parse","--verify","refs/heads/$module")!=0)+{+$log->warn("Checkout failed: $module is not a branch");+print"error 1 Checkout failed: $module is not a branch\n";+chdir"/";+exit;+}+$log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");$ENV{GIT_DIR}=$state->{CVSROOT}."/";
Looks good, haven't tested it yet, though. Care to add a testcase
or should I take care of that?
Gruesse,
--
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/
@@ -770,6 +770,14 @@ sub req_co$log->debug("req_co : ".(defined($data)?$data:"[NULL]"));+if(system("git","rev-parse","--verify","refs/heads/$module")!=0)+{+$log->warn("Checkout failed: $module is not a branch");+print"error 1 Checkout failed: $module is not a branch\n";+chdir"/";+exit;+}+$log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");$ENV{GIT_DIR}=$state->{CVSROOT}."/";
Looks good, haven't tested it yet, though. Care to add a testcase
or should I take care of that?
I would be eternally thankful if you could add the test case, since I am
really short on time.
Ciao,
Dscho
From: Jan Wielemaker <hidden> Date: 2016-06-15 22:43:38
On Thursday 04 October 2007 17:29, Johannes Schindelin wrote:
It does not make sense to check out tags or "HEAD".
Noticed by Jan Wielemaker.
Thanks (though it won't bite me a second time :-)
) + {
+ $log->warn("Checkout failed: $module is not a branch");
+ print "error 1 Checkout failed: $module is not a branch\n";
There are various places where it says print "...", one that even
started some suggestion on what might be wrong, but these things don't
end up at a visible place when using ssh as transport. Its a good idea
this one is at least in the logfile as well. Not sure, but might
printing to stderr work better?
Cheers --- Jan
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:38
Hi,
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
On Thursday 04 October 2007 17:29, Johannes Schindelin wrote:
quoted
It does not make sense to check out tags or "HEAD".
Noticed by Jan Wielemaker.
Thanks (though it won't bite me a second time :-)
Heh. But this is Open Source, so we can make it better for others, too.
Thank you for spending so much time on this, and actually uncovering that
error in cvsserver!
quoted
) + {
+ $log->warn("Checkout failed: $module is not a branch");
+ print "error 1 Checkout failed: $module is not a branch\n";
There are various places where it says print "...", one that even
started some suggestion on what might be wrong, but these things don't
end up at a visible place when using ssh as transport. Its a good idea
this one is at least in the logfile as well. Not sure, but might
printing to stderr work better?
I think not. AFAICT stderr is not visible with cvs either. I somewhat
hoped that the "error 1" was an indicator to the cvs client to show the
message, but that's way beyond my knowledge...
Ciao,
Dscho
From: Frank Lichtenheld <hidden> Date: 2016-06-15 22:43:38
On Thu, Oct 04, 2007 at 07:06:20PM +0200, Jan Wielemaker wrote:
On Thursday 04 October 2007 17:29, Johannes Schindelin wrote:
quoted
) + {
+ $log->warn("Checkout failed: $module is not a branch");
+ print "error 1 Checkout failed: $module is not a branch\n";
There are various places where it says print "...", one that even
started some suggestion on what might be wrong, but these things don't
end up at a visible place when using ssh as transport. Its a good idea
huh?
$ CVS_SERVER=/home/djpig/devel/git/git-cvsserver cvs -d :ext:localhost:/home/djpig/devel/gitcvs.git/ co -d cvswork HEAD
djpig@localhost's password:
server doesn't support gzip-file-contents
fatal: Needed a single revision
Checkout failed: HEAD is not a branch
Gruesse,
--
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/
From: Frank Lichtenheld <hidden> Date: 2016-06-15 22:43:38
Test the behaviour for non-branches (e.g. head) and
non-existant branches. Also make a test checkout with
packed refs.
Signed-off-by: Frank Lichtenheld <redacted>
---
t/t9400-git-cvsserver-server.sh | 48 ++++++++++++++++++++++++++++++++++++--
1 files changed, 45 insertions(+), 3 deletions(-)
How about "! GIT_CONFIG..." instead of the "if..then..else..fi" ?
I don't really care. IIRC I took the idiom from another testfile.
Several other tests in this file already use it, too. So unless
Junio prefers I change all occourences, I will not.
quoted
+ cat cvs.log | grep -q "not a branch" &&
+ test ! -d cvswork2'
+rm -fr cvswork2
Again, for consistency, I'd include this in the test case.
Again, I don't really care. But for consistency with the rest of the
file I will only change it if I'm asked to change all occourences.
Gruesse,
--
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/
Since I do this several times and since it is easier to see what tests
it belongs to if it isn't buried in one of them, I would say "no".
Just to clarify: I meant making an own "test_expect_success", a la "setup"
in many other test scripts.
But I'm not the maintainer, so I'll just shut up.
Ciao,
Dscho
From: Frank Lichtenheld <hidden> Date: 2016-06-15 22:43:38
On Thu, Oct 04, 2007 at 08:17:07PM +0100, Johannes Schindelin wrote:
On Thu, 4 Oct 2007, Frank Lichtenheld wrote:
quoted
On Thu, Oct 04, 2007 at 07:24:05PM +0100, Johannes Schindelin wrote:
quoted
Should this not be in a test_expect_success, too?
Since I do this several times and since it is easier to see what tests
it belongs to if it isn't buried in one of them, I would say "no".
Just to clarify: I meant making an own "test_expect_success", a la "setup"
in many other test scripts.
Hmm, ok, will consider it. But as said, this should then be done for the
whole file at once, so I will definetly not change this particular
patch.
Gruesse,
--
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/
@@ -770,6 +770,14 @@ sub req_co$log->debug("req_co : ".(defined($data)?$data:"[NULL]"));+if(system("git","rev-parse","--verify","refs/heads/$module")!=0)+{+$log->warn("Checkout failed: $module is not a branch");+print"error 1 Checkout failed: $module is not a branch\n";+chdir"/";+exit;+}+$log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");$ENV{GIT_DIR}=$state->{CVSROOT}."/";
I've found a problem with the patch. Since git-rev-parse will produce
output (which will end up at the client and confuse it), we will have to use a fork/exec
combination instead of system to be able to close STDOUT and STDERR of the child.
Should I sent a patch on top of this one or as a replacement?
Gruesse,
--
Frank Lichtenheld [off-list ref]
www: http://www.djpig.de/
@@ -770,6 +770,14 @@ sub req_co$log->debug("req_co : ".(defined($data)?$data:"[NULL]"));+if(system("git","rev-parse","--verify","refs/heads/$module")!=0)+{+$log->warn("Checkout failed: $module is not a branch");+print"error 1 Checkout failed: $module is not a branch\n";+chdir"/";+exit;+}+$log->info("Checking out module '$module' ($state->{CVSROOT}) to '$checkout_path'");$ENV{GIT_DIR}=$state->{CVSROOT}."/";
I've found a problem with the patch. Since git-rev-parse will produce
output (which will end up at the client and confuse it), we will have to use a fork/exec
combination instead of system to be able to close STDOUT and STDERR of the child.
Should I sent a patch on top of this one or as a replacement?
Better a replacement. Otherwise I have to fly to California with a brown
paper bag over my HEAD.
Ciao,
Dscho
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:39
Johannes Schindelin [off-list ref] wrote:
On Thu, 4 Oct 2007, Frank Lichtenheld wrote:
quoted
Should I sent a patch on top of this one or as a replacement?
Better a replacement. Otherwise I have to fly to California with a brown
paper bag over my HEAD.
That may be the safer way to travel. If your head is in a bag you
have no idea what sort of wait in the security line you are about
to face. Or what horrible movie they are showing you on the flight
both over *and* back.
--
Shawn.