[feature request] scale by file size

[nschloe]

I have a repo with a bunch of source files, and some sources files are much larger than others. I'd like to see this reflected in the visual representation, ideally by the size of the dots. Related to https://github.com/acaudwell/Gource/issues/54.

[RickardAndreasAgren]

I'd love to see this aswell, however one must consider that this request might be slightly bigger than imagined. As far as I understand gource simply reads files affected by commits. To implement this you'd need to keep track of the files sizes aswell. If implemented it should preferably be an option as the crunchtime for large projects might increase a fair bit.

Just want to fold in a big "Nice application!" =)

[acaudwell]

There are a few issues with file sizes which has stopped me looking at this previously:

• The spiral file layout algorithm would probably look strange/not work particularly well with different file sizes
• The availability of the file size from the version control system history (the log command may not be able to provide that information)
• How this would be supported by custom log

[RickardAndreasAgren]

The layout could be okay if each file cluster is sorted by size, however it depends on how easy it is to change just that in regards to how the circles position themselves. If its a set pattern it's going to be clunky, However if they are "attached" to whichever circle is the one closer to center it should be fine.

I'd dig in to the code to find out myself if I wasn't working to the point of frying my brain most days.

[Guildenstern]

instead of file size you can visualize the change size. To obtain this, you can get the diff to previous commit + some regex magic followed by wc

for layouting, the layouter can still assume, that all files are same size. Also color saturation can be used instead of circle-size

[luncht1me]

^ This. Who's up for it?

[rhbvkleef]

I would love to see this too. It certainly reflects work (slightly?) better. and can look quite cool

[OneManMobile]

I would love for this to happen.

I have created a BountySource for it on 15 dollars. Not much, but I think Gource is a great project and want to give it a tip, (and a pull in the direction that could give it more use for myself and others).

Thank you for this project, it is a great visualization tool.

https://www.bountysource.com/issues/41113299-feature-request-scale-by-file-size

[bobdesaunois]

Would love to see this feature!

[mschilli87]

@bobdesaunois

Would love to see this feature!

After over a year, there is still one backer only on @OneManMobile's bounty. :wink:

[bobdesaunois]

@mschilli87 I have added $50 to the current bounty, would love to see this feature happen! 😄

[bobdesaunois]

Added another $35, adding the total bounty up to $100. Hopefully this will draw in some more attention :)

[simonbaird]

Arrived here in 2021 via a goole search for "gource file size"...

Thoughts:

• Need some special handling for zero size files like .keep, otherwise they'll be invisible.
• I expect it would work better with a non-linear scale, perhaps logarithmic, to reduce the range of dot sizes.
• The scale factor should be configurable via the command line so you can tweak it for best results.

[TomFryers]

Regarding scaling, one thing to try is having r³ be proportional to the number of lines. This produces a smaller range of sizes than equal areas (which would be r²), while still being ‘realistic’ if you consider the blobs to be spheres.

Perhaps add one to all file lengths to solve the zero-size file problem. You can think of this virtual ‘line’ as the file name and metadata if you really want.

[Ben-Fenner]

This is 1 of 4 issues for this request. The others are: https://github.com/acaudwell/Gource/issues/54 https://github.com/acaudwell/Gource/issues/91 (this very issue you're reading now) https://github.com/acaudwell/Gource/issues/147 https://github.com/acaudwell/Gource/issues/223

I was going to suggest this feature but found these instead. It would be nice to see, and I agree logarithmic sizing is probably best.

[zimonitrome]

Time for the annual comment on this 7 year old issue.

Some thoughts:

There are a few issues with file sizes which has stopped me looking at this previously:

• The spiral file layout algorithm would probably look strange/not work particularly well with different file sizes
• The availability of the file size from the version control system history (the log command may not be able to provide that information)
• How this would be supported by custom log

• Ideally the spiral layout would be replaced with with a more dynamic "physics based" layout where nodes could expand more freely. Very much easier said than done.
• File size would be replaced with number of lines or change size like suggested above.
• An easy first step would be to simply ignore custom log or not support it when visualizing size.

• Need some special handling for zero size files like .keep, otherwise they'll be invisible.
• I expect it would work better with a non-linear scale, perhaps logarithmic, to reduce the range of dot sizes.
• The scale factor should be configurable via the command line so you can tweak it for best results.

• I imagine files (nodes) having a minimum size.
• And yes logarithmic scale seems like a no brainer OR an otherwise relative scale to other project files.

Regarding bounty:

I would love for this to happen.

I have created a BountySource for it on 15 dollars. Not much, but I think Gource is a great project and want to give it a tip, (and a pull in the direction that could give it more use for myself and others).

Thank you for this project, it is a great visualization tool.

https://www.bountysource.com/issues/41113299-feature-request-scale-by-file-size

It's really sad that Bountysource shut down. This would have been an issue I'd be willing to donate to crowdsource. Are any similar services available nowadays?

A first step could be to implement #136 to get the lines data in the Node class. And a second step could be to just scale the nodes without taking layout into account.