Crucible: comparison of renamed files / mark comments as "to be applied"

[Oleg Klimin]

Hi!

We are using Crucible for code review, and using git as RCS. And there are two things that are really painful:

1. Renamed files. Everytime this happens during refactoring - renaming is shown as deleted file and new file. No way to compare them. So, if there were changes except renaming (and usually there is such a change), it becomes pretty hard to find those differences. I noticed the ticket https://jira.atlassian.com/browse/CRUC-5768, but it's already more than 3 years old, and not even assigned on anyone. Any development in this area? Because it really hurts.
2. All comments in the review are either unread or read. There is possibility to add them to Favorites. What our team are really lacking is the possibility to mark the comment as "to be applied". Attempts to mark such comments as "unread", leads to impossibilty to differentiate files with new comments from those that are marked as "todo". Try to use Favorites - and you can't see directly in the review, which files contains the comments to be applied. As an author of review, I would like to mark some comments like "those I need to apply". As a reviewer, I would like to mark some comments like "those I would like to check and ensure that they were applied and not missed". Now we have to re-scan the whole review, and taking into account the fact that some comments are hidden - it becomes painful both for the author and for the reviewer. Any changes here?

Thanks in advance!

[Aleksandr Kuznetcov]

Looks like you need to use "-M" and "-C" options:

C:\Data\NetBeansProjects>git show -M -C
commit 23e1e3f4fb08a53cd0703383c3e7ce609981199d
Author: Alexander K
Date: Tue Apr 19 13:55:56 2016 -0700
Renamed test
diff --git a/Test.txt b/Test1.txt
similarity index 100%
rename from Test.txt
rename to Test1.txt

[Oleg Klimin]

Hi Felipe,

While the files are not committed, it is possible to see that it was renaming. And, yes, when commit is done, just "git show" doesn't show the renamings, but... Even then you can still do:

git diff -M --summary commit_from commit_to

which in your case is, possibly (I might mistake the commit IDs, possibly they should be vice versa):

git diff -M --summary 55d5dd1 b18a10b

The output of that command will show the renamings.

Thanks,

Oleg

[Felipe Kraemer]

Hi Oleg,

Not only FishEye/Crucible will show the old file being deleted and the new one being created. This happens in Git as well. In the commands below, I have renamed a file, committed it, and showed the diff:

ecrmac-01:mygitrepo fkraemer$ git mv Test.txt Test1.txt
ecrmac-01:mygitrepo fkraemer$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	renamed:    Test.txt -> Test1.txt
#
ecrmac-01:mygitrepo fkraemer$ git commit -m "Committing Test1.txt"
[master b18a10b] Committing Test1.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Test.txt => Test1.txt (100%)


ecrmac-01:mygitrepo fkraemer$ git show
commit b18a10b4debdca6e77fec185c1673e336bce91fd
Author: Felipe Kraemer <fkraemer@atlassian.com>
Date:   Thu Oct 23 15:02:34 2014 -0200
    Committing Test1.txt
diff --git a/Test.txt b/Test.txt
deleted file mode 100644
index 55d5dd1..0000000
--- a/Test.txt
+++ /dev/null
@@ -1 +0,0 @@
-This is a test!
diff --git a/Test1.txt b/Test1.txt
new file mode 100644
index 0000000..55d5dd1
--- /dev/null
+++ b/Test1.txt
@@ -0,0 +1 @@
+This is a test!

As can be seen above, Git itself is showing the file with the old name as deleted ("deleted file mode 100644") and the file with the new name as a new file ("new file mode 100644"). The same happens on directories or packages that get renamed. That's why in FishEye/Crucible renaming is shown as deleted and new file as well.

Kind regards,
Felipe Kraemer
Atlassian Support

[Oleg Klimin]

Hi Felipe,

Thanks for reply!

1. Usually I already split such changes on two commits - either rename than change, or vice versa. The issue is that not all people follow that, and I can understand them - during refactoring you may move the Java class to another package, or rename some resource file in Eclipse during refactoring. Now the IDE automatically adds such changes like renaming to commit, so it is even more manual work to make two commits. And of course, people just forget or just lazy to do that in such a way. In all cases, support of such feature in a tool will be a great help. In development project, renaming the classes after refactoring / selecting better name is quite common, and it is always pain in the ... eyes to review that 
2. Voted. Subscribed. Commented. Waiting for implementation 

Best Regards,

Oleg

[Felipe Kraemer]

Hi Oleg,

1. If you rename and commit the file, and then edit what's needed and commit again, this problem would be solved, wouldn't it?
2. This feature has already been requested and is being tracked here: https://jira.atlassian.com/browse/CRUC-3972
   Feel free to vote for the issue and/or leave a comment to describe your use-case in more detail. It will help our development team to build a solution that meets your needs.
   If you want to know more about how we prioritise feature requests, take a look at our policy.
   

Kind regards,
Felipe Kraemer
Atlassian Support