Defect #3832
closed
Git blame/annotate fails on moved files
Added by Jiongliang Zhang over 15 years ago.
Updated over 14 years ago.
Description
1. Error: The entry does not exist or can not be annotated, it happens at many files. And the files have so Chinese words, does it because unicode or something?
But I really sure its exist.
Parameters: {"rev"=>"master", "action"=>"annotate", "id"=>"scm-test", "controller"=>"repositories", "path"=>["source", "engine", "engine", "engine.c"]}
Rendering template within layouts/base
Completed in 89ms (View: 15, DB: 9) | 500 Internal Server Error [http://172.25.78.117/projects/scm-test/repository/revisions/master/annotate/source/engine/engine/engine.c]
2. Operation steps:
- 1. when I rename a directory "src" to "source" (git), no edit any files.
- 2. generate a commit object "ddddddd"(git),
- 3. press "Repository" (redmine),
- 4. press "ddddddd" revision,(redmine), but it shows the working tree fiels, like: files.txt
- 5. press "file.txt" link, then
- 6. error happen: The entry or revision was not found in the repository.
Files
- Affected version (unused) set to devel
What revision of Redmine are you using?
What if you delete that repository from Redmine and reenter it? This would purge Redmine's old cache of the repository and refresh it using the latest git code.
I tried it, and I also restart mongrel_cluster and apache2, but it happens again. Does it can happen in your system?
More or less a "me too", I'm running version: d5f181f47e9c4a5765c3ae76ad9b0b06cac7186d from github.
I also tried to delete from changes, changesets, changesets_issues whithout success.
Trying the git shellout commands from command line works fine.
And this are the last line seen in production.log
SQL (0.2ms) SELECT count(*) AS count_all FROM `versions` WHERE (`versions`.project_id = 1)
Completed in 176ms (View: 11, DB: 1) | 500 Internal Server Error [https://XXX/redmine-testing/projects/puppet/repository/revisions/8b5672bdf770072dd54352b1556844f86b4f0e05/annotate/puppet/bin/encrypt-file]
Could you give advice how to proceed debugging this issue?
I think, I could track this down.
When moving a file in the repository, the git blame output changes in a way redmine can't cope with.
[master!test-blame]$ git blame -l e39aadbf021a871d80fbb969d99d36bdb4ed7a7f -- myfirstfile
e39aadbf021a871d80fbb969d99d36bdb4ed7a7f (Bernhard 2009-11-11 14:53:40 +0100 1) a
[master!test-blame]$ git blame -l bf72277c133f719557929dc86fda529453adf863 -- myfirstmove/myfirstfile
e39aadbf021a871d80fbb969d99d36bdb4ed7a7f myfirstfile (Bernhard 2009-11-11 14:53:40 +0100 1) a
[master!test-blame]$
See the additional myfirstfile in the 2nd blame output, which refers to the file before the move.
I've created a patch which resolves the problem for me, knowing it is far away from clean ruby.
To make parsing simpler I chose to use "git blame -p" which seem to be designed for parsing.
@Jiongliang Zhang: can you verify this is fixed with this patch?
updated patch to "blame unless blame.empty?"
Since git branch was backported to stable (0.8.7), I also tried it with the latest stable, same problem.
It's really easy to reproduce:
- Empty project, empty git repo
- add file to repo
- move file to a subdirectory
- try to annotate the moved file => err 500
For completeness's sake: git version 1.6.5.2
br,
bernhard
PS: Affected version should be set to 0.8.7
Hello,
I have exactly the same kind of problem:
$ git --git-dir /tmp/test/.git blame l '1609c5d7425d48784ac6e2fe12eb8557c171348e' - 'test.c'
^1609c5d7425d48784ac6e2fe12eb8557c171348 (Arnaud Fontaine 2009-12-08 15:03:13 +0100 1) #include <stdio.h>
The last digit of the Git revision is missing as there is a '^' at the beginning (I don't know why though). Therefore, I think that using `-p' instead of `-l' would be the way to go. Thanks much for applying the patch submitted by Bernhard.
Regards,
Arnaud Fontaine
how can I apply this patch?
Thanks
Nevermind...
I've found the command! thanks for the patch
- Subject changed from Git SCM show error to Git blame/annotate fails on moved files
- Status changed from New to Resolved
- Assignee changed from Eric Davis to Jean-Philippe Lang
- Target version set to 0.9.4
- Resolution set to Fixed
Patch committed with slight changes and tests in r3513.
Thanks for taking care, but when doing the slightly change there was introduced some consistency error.
in svn annotate in each line the user is prepended
in git annotate now only on 1st occurrence the user is prepended
I think that was also the reason why I used auth as hash.
Cherry picked, fix confirmed.
Thanks,
bernhard
- Status changed from Resolved to Closed
Also available in: Atom
PDF