We’ve implemented a batch of improvements in the branch/cset/label diff window in the last months. Some of the improvements are pretty recent and some others have been around for months already. I’ll be walking through them and explaining how they help when running diffs on a daily basis.
Improved diff groups
Availability: 184.108.40.2063 (Sep 12th 2014) and 220.127.116.115 (Sep 19th 2014).
The first feature is the ability to group together files and directories that only differ in file system permissions (typical scenario when some files get executable flag on Linux). Now the files that only differ in file system permissions are grouped together so you can better focus on what was actually modified.
The goal here is to let you focus on the real changes when diffing code for a review or when figuring out why a bug occurred, by grouping away potentially uninteresting changes.
The second feature is a slight modification since we released Item Merge Tracking last year. Now the files that were in changed/changed merge conflicts will show up in their own category:
And this is how the same info was grouped before:
As you can see now he highlight the “changed/changed” and put them at the very beginning of the list so you can focus first on the diffs of files which were modified by both contributors during a merge, and hence are potentially worth reviewing.
Availability: 18.104.22.1686 (March 3rd 2014) and 22.214.171.1248 (March 10th 2014).
There’s a story behind this feature: sometimes you find yourself reviewing a task where the developer modified a huge number of files, like 200 or so.
You launch the diff and then you see the counter with a big number on it: 100, 200, 250 files… whatever. Your feeling will be: “oh god! Let’s go and grab some coffee first”. Which, in short, means that huge reviews are extremely unproductive because you enter in this state of mood of “this will take a loooooong time”.
And sometimes that’s correct and you truly have to spend a long time.
But chances are that many of the files changed by your colleague only contain trivial changes. Like a rename on a method that affects a bunch of files, but all this files only have a trivial modification.
How can you figure out beforehand? Well, that’s why we’ve introduced “analyze changes”.
You click on the new “analyze differences” button and then Plastic will use cloc to calculate the lines of code being modified. You can see it running in my review with 284 files below:
And here goes the result once the changes were classified:
As you can see there’s a new SLOC column where you see a summary of the lines of code being added, changed and deleted (since it uses SLOC and not LOC, there will be cases where changes only affected comments or white lines and hence they’ll show up as zero changes!).
You can sort the column and then check how many files have really “big changes” and it will have a positive effect on your mood and willingness to go through the entire list, which at the end of the day means increased productivity :-)
In my screenshot you can see how the selected file just contains a namespace change… which is not a big deal to review and in fact in my example this refactor affected more than 180 files out of 280, not bad.
This is the first step towards true “semantic multi-file diff” :-)
Find in files
Available since: 126.96.36.1994 (Jun 6th 2014) and 188.8.131.525 (July 1st 2014).
Sometimes you’re diffing a branch and then you would like to find something (a method call, a given text or comment) inside the files being diffed.
That’s why we added “find in files” to the diff window: click on the new “find in files” button or “CTRL+SHIFT+F” and the following panel will show up:
You can enter the pattern to find, then decide whether you want to search in both sides or only one of them, select the extension or whether you want to select the search to the filtered files in the diff window.
And the results are displayed as follows:
With the occurrences of the left and right sides separated to ease the navigation.
In my case I was looking for the word “comment” and it is clearly more common before the change, which means the word was deleted from the file.
Our plan is to implement another feature on top: “search only in diffs” to restrict the search to the text blocks which were really modified. This is useful, for instance, to see if a certain method call has been really used in the new code or not.
Annotate each contributor
Available since: 184.108.40.2067 (Jun 18th 2014) and 220.127.116.118 (Jun 26th 2014).
We added the option to launch the annotate from within the diff view so you can instantly see the detailed information about each line of each of the two sides of a diff.
I find it especially useful when going through complex merges: look at the screenshot above. Do you see the “Yes” at the end of the annotate? It means this line was modified during a merge. Which means the two contributors to the merge don’t contain the line but it was actually edited during the merge (at least prior to the checkin). This information is very useful to figure out what was really changed manually and what simply comes directly from one of the merge contributors.
As it happens with some of the other features explained in this blog post, this is just a first step. We’re working on more improvements to item merge tracking to be able to display on files in the “changed-changed” group exactly which lines come from merges or were modified on the branch.
Info about binary files
Available since: 18.104.22.1682 (Aug 6th 2014) and 22.214.171.1243 (Aug 8th 2014).
Sometimes you’re diffing a branch and there are binary files that can’t be diffed. So far we were just displaying a message telling “diff not available” (although you can CTRL+D to launch the external diff, for images for instance). Now we display useful metadata to understand the change:
The date and size and author are especially useful to understand what is going on with the file.
For images our plan is to embed the Image Diff here (check the gallery to find out more about the tool).