How do we track the line-by-line evolution of a text file?

[nelsonic]

Imagine that you are collaboratively editing a text file (or group of files i.e. a "software project"!) and you want to track exactly the order in which the text was added so that you can create a "timeline" style of UI to display exactly when a line was added/updated.

This is possible with Git "blame" e.g: https://github.com/dwyl/learn-tdd/blame/master/README.md We can see who added each line:

However if you look at the number of commits in the project:

It's totally dwarfed by the number of lines: https://github.com/dwyl/learn-tdd/graphs/contributors

That's actually a good thing, if we had a git commit for each line there would be thousands of them ...

Perhaps there's a different (but related) question to be asked/answered here: does it matter if your project has a lot of commits?

[nelsonic]

Searched for: https://www.google.pt/search?q=too+many+git+commits .then read a bunch of posts about git commits:

• https://services.github.com/on-demand/git-trouble/too-many-commits
• https://www.reddit.com/r/git/comments/3afubp/is_there_such_thing_as_doing_too_many_commits/
• http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
• https://softwareengineering.stackexchange.com/questions/74764/how-often-should-i-do-you-make-commits
• https://crealytics.com/blog/5-reasons-keeping-git-commits-small/
• https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/
• https://randyfay.com/content/avoiding-git-disasters-gory-story

Initial conclusion: most people recommend/prefer (more) smaller commits to (fewer) large ones.

The obvious downside of having many commits is forcing "CI" to run each time costs resources...