This turned out to be due to a permissions error. Some of the files
in the git repository were not readable by the webserver user. Once I
fixed that, the upload to ReviewBoard worked fine. Thank you for your
help, Christian!
--Paul
On Sep 23, 6:38 pm, Paul Lynch plynch...@gmail.com wrote:
I recently switched from cvs to git. Our procedure with ReviewBoard
with git is now similar to what we were doing before: commit changes,
do a git pull, then create a diff of the unpushed changes with git
diff FETCH_HEAD..HEAD, then push the changes. Very frequently, when
I try to upload such a
How is Review Board set up with that repository? Is it using a local clone?
If so, you have to have something set up so that the clone is always
up-to-date, or you'll hit errors like this.
I generally recommend setting up something like cgit on the repository and
then using that as the Raw File
The Review Board repository path setting is the (bare) git
repository that is our upstream repository to which we push our
changes. I can see the sha1s that Review Board is complaining about
in that repository, so they do exist there.
On Sep 23, 5:19 pm, Christian Hammond chip...@chipx86.com
Ah okay.
How did you generate/upload the diff?
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Fri, Sep 23, 2011 at 2:22 PM, Paul Lynch plynch...@gmail.com wrote:
The Review Board repository path setting
git diff FETCH_HEAD..HEAD
(before the push). After that a push was done, and then I tried to
upload the file. I have also done a pull in another clone of the
repository, and can see the files there too.
Uploading was done through the Review Board web site (now at 1.6.1)
using the New Review
So off-hand, I don't know why you're hitting this, but let's just run
through a couple more things.
During upload time, when we go to verify a file's existence, we run:
git --git-dir=repo path cat-file -t revision
If you run that on your bare repo, does that still work? What do you see?
If
It works, but if my current working directory is not in a git
repository, I also get a fatal error, after which it outputs the
type. For example:
git --git-dir=/proj/git/def.git cat-file -t febdf30
fatal: Not a git repository (or any of the parent directories): .git
blob
(But not that it does
I wouldn't expect it to need to be in that directory. We do look for a
fatal: but only for Not a valid object name. However, it's very likely
that the error code is when you execute that isn't 0, so we're failing.
So for that repo, if you're in /proj/git/def.git, it works?
What version of git is
Yes. I tried cd'ing to that /proj/git/def.git, and the fatal error
message went away.
$ git --version
git version 1.7.0.4
On Sep 23, 6:24 pm, Christian Hammond chip...@chipx86.com wrote:
I wouldn't expect it to need to be in that directory. We do look for a
fatal: but only for Not a valid
It does seem that the error status is 0:
git --git-dir=/proj/git/def.git cat-file -t febdf30
fatal: Not a git repository (or any of the parent directories): .git
blob
echo $?
0
I just notice an odd thing, though. I logged into two other systems
that can see that repository (we have it mounted
11 matches
Mail list logo
