>> 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.
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
-
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
