search

acaudwell / Gource

software version control visualization
https://gource.io
GNU General Public License v3.0
11.54k stars 723 forks source link

[Feature request] Color files by number of changes, size by file size #223

Open iCodeIT opened 5 years ago

iCodeIT commented 5 years ago

Option for setting blob-size to match file size. Color green-yellow-red for how often file was changed in the last x days Color green-yellow-red for how many different developers changed the file in the last x days

Ryuno-Ki commented 5 years ago

What about people who are red-green-colourblind? A recommendation would be to not rely on colour alone for meaning.

davidjeddy commented 5 years ago

Or allow the 'new', 'medium', 'old' color to be defined. Then the question becomes how to define the count of days between the different colorization. I can think of a greater than X days be color y with a cross fade value.

--asset-age=>0 --asset-color=white --asset-fade-3
--asset-age=>10 --asset-color=yellow --asset-fade-3
--asset-age=>20 --asset-color=brown --asset-fade-3
...

A new file would be white from day 0 to +/- day 10; where for 3 days prior and after the 10th day the color would transition from white to yellow. At +/- day 20 the color would fade from yellow to brown. If no 0 day color is provided use the default color. If a range is skipped, continue using the previous color.

Thoughts?

Ryuno-Ki commented 5 years ago

I'd research for theory about colour palettes of heatmaps.

You could also think in terms of HSL instead of RGB.

But again, colour shouldn't be the sole mean of transporting meaning. For example, I could setup my OS in HighContrast mode and see everything in yellow-on-black.

iCodeIT commented 5 years ago

I would be fine with colors going from dark to light.

What I want the color to convey is not how long ago the file was modified, but how often it has been modified in the last x days. If a file in a large repository (4000+ plus files) has been modified more than 50 times in the last 6 months it might be an indicator, that this file should be refactored/redesigned due to too high coupling and/or to much responsibility - so violating single responsibility. This would actually make this beautiful visualization into a useful tool.

Likewise the size of the blob relating to file size might also be a good visualization help.

Ryuno-Ki commented 5 years ago

Sorry for getting off-topic now, but that reminded me on some other ideas how to spot code which could be in need of a refactor.

Check out item 5 of https://pythonbytes.fm/episodes/show/155/guido-van-rossum-retires