Feature request: recursively-calculated, sortable lines-changed column

Applications
,
1

A common use case I have is comparing two versions of a source code repository with the goal of finding and reviewing as many differences as possible. This means my goal is to find the area(s) of the codebase with the most changes, regardless of where in the directory hierarchy those chagnes fall.

Currently the directory comparison only sorts alphabetically, which means manually scanning through the visual indicator on the righthand side for areas of high change density. There is no indicator shown for directories as far as I can tell.

It would be very useful to add a new column (or three) to the directory view showing total lines added/removed/changed. This could be computed per-file, or per-directory by defining the number of lines added in a directory as the sum of the lines added for each file within the directory.

This could be calculated recursively, which would make it possible to quickly drill into the part of the codebase with the most changes, regardless of whether a single file contains many changes, or a single directory contains many files, each with a few changes.

Some disk usage analyzer apps such as the Ubuntu app formerly known as baobab and the console app ncdu utilize this workflow.

Would anyone else be interested in a feature like this?

2

I’m not sure whether you’re talking about doing this for folder or version control comparison here. Meld doesn’t calculate diffs for individual files in folder comparison mode, and honestly I’m not sure I would want to support that given how complex it would probably be to do so. For version control view I feel like something like this makes more sense because we could lean on the diff stat provided by the version control system itself, and also because showing a diffstat in version control UIs is pretty common.

3

I am using it in folder compare mode. I did not realize meld doesn’t calculate individual file diffs in folder diff mode but I see now why that makes sense. I don’t really understand what additional complexity there would be beyond generating a full diff associated with each file, which meld already does.

If it was significantly easier I suppose I could use git diff --no-index to generate the diff and then feed it in, but then meld would still need to parse it, presumably into the same data structures.