It actually looks like the locally synchronized copy on the review board server has some corruption (the "bad file"). I'd suggest doing a new full clone.
-David On Sun, Aug 7, 2016 at 3:07 AM fluzz <[email protected]> wrote: > > > Le dimanche 7 août 2016 04:33:56 UTC+2, David Trowbridge a écrit : >> >> You really should be using --full-index on your git diffs (or even >> better, rbt post/rbt diff) >> >> > Yes, I used full indices, or RB complains, advising to use --full-index > > Alright, let me give you some more details. > > On my computer, I create a first patch by changing an already pushed file: > echo "one more line" >> README.md > git add README.md > git commit -m "Add one more line to README" > > Get the commit hash: > git log -n 1 --oneline --no-abbrev-commit > --> 640c72555ff05bb1defdfa408acbce69d8ad4dec Add one more line to > README > > Get the indices of the modified file: > git diff-tree 640c72555ff05bb1defdfa408acbce69d8ad4dec > --> :100644 100644 8222229d589f498854dde3c062be8be0c5648a62 > aca23a7590f0ddeb40d9eaa8e7a9988c1978960e M README.md > > So, 8222229d589f498854dde3c062be8be0c5648a62 is the blob already pushed > aca23a7590f0ddeb40d9eaa8e7a9988c1978960e is the blob locally > committed > > Now, patch again the file, without committing it locally: > echo "an other line" >> README.md > > Get the diff: > git diff --full-index README.md > --> diff --git a/README.md b/README.md > --> index > aca23a7590f0ddeb40d9eaa8e7a9988c1978960e..629e72cf3f5b094fa17f91ceae93c7334ddace2f > 100644 > > So, as expected, the latest version of the file is based on > aca23a7590f0ddeb40d9eaa8e7a9988c1978960e, the blob locally committed > > > Now, on the RB server, which uses a local synchronized copy of our > repository, with git 1.7.2.5 > > Check if aca23a7590f0ddeb40d9eaa8e7a9988c1978960e exists locally (If not, > a parent diff should be requested): > git cat-file -t aca23a7590f0ddeb40d9eaa8e7a9988c1978960e > --> error: unable to find aca23a7590f0ddeb40d9eaa8e7a9988c1978960e > --> fatal: git cat-file aca23a7590f0ddeb40d9eaa8e7a9988c1978960e: > bad file > > That's not the error message parsed by scmtools/git.py > > If I try the same command, but with a partial index: > git cat-file -t aca23a7590f0 > --> fatal: Not a valid object name aca23a7590f0 > > So my conclusion: > The error message parsed by scmtool.git.py is only for partial index of > non-existing hash... > As RB requests full indices, then the "error: unable to find...." message > is the one to parse > > > And now, on an other server, with a more recent version of git (2.5.1): > git cat-file -t aca23a7590f0ddeb40d9eaa8e7a9988c1978960e > --> fatal: git cat-file: could not get object info > > As I said, the error message changed with git 1.8.something > > > Is there something that I did not get ? > > I will also check with rbt, and let you know how it behaves. > > > -- > Supercharge your Review Board with Power Pack: > https://www.reviewboard.org/powerpack/ > Want us to host Review Board for you? Check out RBCommons: > https://rbcommons.com/ > Happy user? Let us know! https://www.reviewboard.org/users/ > --- > You received this message because you are subscribed to the Google Groups > "reviewboard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
