Community
Participate
Working Groups
Build Identifier: 20090920-1017 Currently in my Resource History view, the version graph does not contain any versions prior to move/rename of a resource. It should be possible to enable following renames for a resource in the resource history view, like using 'git log --follow'. Reproducible: Always Steps to Reproduce: 1. Select a resource and click Team -> Show in Resource History 2. The version tree graph is shown in the Resource History view 3. The graph does not show any versions before resource was moved/renamed
Forgot to say that I'm using EGit incubation 0.6.0.201001271947
In my opinion this is not an enhancement but a bug in egit.
*** Bug 329560 has been marked as a duplicate of this bug. ***
Is there only work in EGit to do (means, is JGit capable of that function), or do we have to implement this functionality in JGit first?
the rename detection itself is already in JGit (see RenameDetectorTest.java). You can also see the Log.java command to see how it is used. If Egit uses low-level JGit classes to produce the content of the history page then it should use the same code as in Log.java to enable rename detection.
I thought this was the whole point of git? Without this I may as well use SVN.
(In reply to comment #6) > I thought this was the whole point of git? Without this I may as well use SVN. If you still think that... there's more to learn. http://whygitisbetterthanx.com/ https://git.wiki.kernel.org/index.php/GitSvnComparsion EGit is still in incubation, be patient as we progress. We're doing our best with frequent releases every 2-3 months.
(In reply to comment #7) > (In reply to comment #6) > > I thought this was the whole point of git? Without this I may as well use SVN. > > If you still think that... there's more to learn. > > http://whygitisbetterthanx.com/ > https://git.wiki.kernel.org/index.php/GitSvnComparsion > > EGit is still in incubation, be patient as we progress. We're doing our best > with frequent releases every 2-3 months. I know...I know...I was just surprised that this feature wasn't available yet. ;-)
Created attachment 198091 [details] This patch adds the "Follow Renames" feature to EGit Here is a patch that add the "Follow Renames" feature to current EGit code. I'll submit it in Gerrit for a review.
When this bug is fixed will it also fix the issue when showing the blame annotations for a file? Right now if you show the blame annotations for a moved file it blames the whole content of the file on the commit that did the move/rename.
add myself to cc
*** Bug 356830 has been marked as a duplicate of this bug. ***
Seems this is http://egit.eclipse.org/r/#change,3743
(In reply to comment #10) > When this bug is fixed will it also fix the issue when showing the blame > annotations for a file? An attempt to fix this is at http://egit.eclipse.org/r/4368
merged egit changes 7e8fef95439e087e2621d9f33c6790675a1cfa57 and 1ba41922b09d98eb7aeb72d94e41e4a9b7b6acc0 and jgit change 98d4bd6d36d98940f5fd0b6a3e20147cb96903c0
patch proposed to make blame follow renames is still pending http://egit.eclipse.org/r/#change,4368
Using the nightly build of EGit: Eclipse EGit 1.2.0.201111090740 org.eclipse.egit.feature.group Eclipse EGit I've noticed that when I'm trying to compare a file that has been moved to a different subdirectory, it seems the compare fails because it tries to get the file according to only one of the compared files. I don't know if this is the right place to put this information, or should it be located in a new bug.
(In reply to comment #17) Yep, that's what I also see in 1.3.0.201201031923: - check 'History view menu > Show > Follow Renames' - select Resource filter - show history of a renamed file - select 2 versions - context menu > Compare with Each Other => right side says "HTML2TextReaderTest.java" is not in commit 9652ad7296f5eb... Blame Annotations work fine though.
"Show > Follow Renames" feature is not working for me (commits before resource was moved/renamed are not shown). "git log --follow path/to/file" via the command line works ok. Tested Eclipse/egit/JGit versions: Helios SR1/1.2.0.201112221803-r/1.2.0.201112221803-r Indigo SR1/1.2.0.201112221803-r/1.2.0.201112221803-r Indigo SR1/1.3.0.201201170515/1.3.0.201201161708
[Batch change] Remove passed Target Milestones If anyone on CC list is going to fix/implement this, feel free to assign a new, post-1.3/2.0, target milestone.
The API need to be redesigned. See https://git.eclipse.org/r/#/c/5416/
Maybe Carsten has some ideas about this
I suffered from the problem too but was able to resolve it by setting git configuration option diff.renameLimit to some big number like this: git config diff.renameLimit 100000 If this option is not set, jGit does not follow renames for commits with number of added files larger than 200 . This number is hard coded into implementation of jGit. It can be critical if you rename packages or move many classes in one commit. Regards, Dimitry
(In reply to Markus Keller from comment #18) > (In reply to comment #17) > Yep, that's what I also see in 1.3.0.201201031923: > - check 'History view menu > Show > Follow Renames' > - select Resource filter > - show history of a renamed file > - select 2 versions > - context menu > Compare with Each Other > => right side says "HTML2TextReaderTest.java" is not in commit > 9652ad7296f5eb... > > Blame Annotations work fine though. I verified this is still an issue in the EGit release for Kepler. The right side of the editor is blank, showing the "is not in commit" message. Additionally, in the Revision Details area, the "Compare with Workspace" right click option is disabled. I don't see any workaround here for getting the compare editor working. There does not seem to be any way to compare an older revision of a file that was moved/renamed with the current version in the workspace. The "Follow Renames" feature only allows the history view to shows the older revisions similar to --follow. However, this has very limited use if I can't do any comparisons before and after the move/rename.
The problem with compare is tracked in bug 374722. Blame seems to work correctly with a renamed file here. Closing this, as the general feature of following renames was implemented. Please open specific bugs for any remaining issues that are not yet reported.
