Is there a particular reason git-stats keeps it's own record of git activity?

[ionicabizau]

Is there a particular reason git-stats keeps it's own record of git activity?

[IonicaBizau]

Hey @h0dgep0dge! ✨

The main purpose of this project is to create a GitHub contributions like calendar for the local commits. That meas I don't want to parse always the commit history of all user projects but to keep the history in a database-like file.

However, in the new version (which is not yet merged into the main branch), git-stats supports such a feature.

I'm not sure, but I guess you can install the new version like this:

$ npm i -g IonicaBizau/git-stats#v2.0.0

Then, run git-stats -h to see the help output. I guess you're looking for the following command (/cc #55):

$ cd to/my/big/repository
$ git-stats --global-activity # or git-stats -g

Then you should see the repository related activity. 😄

Btw, please check #47 for more information and feedback for the new version. Would like to hear your feedback! 📣

[h0dgep0dge]

The main purpose of this project is to create a GitHub contributions like calendar for the local commits. That meas I don't want to parse always the commit history of all user projects but to keep the history in a database-like file.

This seems like a non-sequitur to me. Why would you need to keep your own commit history in your own database, when you already have a git repository that is exactly that?

[IonicaBizau]

Why would you need to keep your own commit history in your own database, when you already have a git repository that is exactly that?

I guess you're missing the point here. git-stats stores a global history of all user projects (those that are imported, for sure) and inserts automatically new commits if the user wanted to do so.

It would be impossible to parse all the user projects when you run git-stats because you can't know where they are stored (e.g. not all are cloned locally), also it would take a long time to parse everything.

Does it make sense?

[h0dgep0dge]

It would be impossible to parse all the user projects when you run git-stats because you can't know where they are stored (e.g. not all are cloned locally), also it would take a long time to parse everything.

It would be possible to parse all projects if they're listed in a configuration file, and that could include repos that aren't cloned locally (albeit at a large cost), and the problem of parse time could be solved with caching. I suppose it does make sense, I think it's just an architecture decision I might have made differently, and it somewhat conflicts with my understanding of the design philosophy of git itself.

I would like to say again, it is a very cool tool, I just might not have done it exactly like it's been done here.

[IonicaBizau]

@h0dgep0dge And then how do you solve the parsing caching? What happens if the repository doesn't have a remote and gets deleted? Such a configuration file could make sense for the git-stats-importer, but not for git-stats. Peace. 😄

[h0dgep0dge]

And then how do you solve the parsing caching?

You have stored in cache the statistics for a particular repo, and up to which commit those stats cover. When invoked, the program would start at the given commit or branch, working backwards sucking up the data until it hits the previously recorded commit. You would only get a noticeable delay if you'd committed thousands of times since the last time the program was run.

What happens if the repository doesn't have a remote and gets deleted?

fatal: repository 'your/repo' does not exist If the user has deleted the repo, they either meant to do it, they can clone it back from somewhere else, or they deleted their only copy by accident. In each of these cases, either it's fine, or the user is an idiot with bigger problems than if git-stats will work properly.

Such a configuration file could make sense for the git-stats-importer, but not for git-stats

Why wouldn't a configuration file make sense? Either way you need to store data, it seems more straight forward to have the user run git-stats track this/repository than it is to configure each of their repositories with a hook into git-stats, do most git users even know what hooks are?

Peace. 😄

... not sure if friendly or arrogant ...

[IonicaBizau]

And I'm curious where you would store that cache. Probably in a file, right? For speed and functionality, I chose to store all the commits (unique hashes) in a data store file (default: ~/.git-stats).

Parsing tasks should be done in the importer, not here. The git-stats project only takes the input data (in the case of calendar the data file) and shows the graph.

No worries, I'm friendly. 😸

[h0dgep0dge]

What's the difference between reading all the commits from ~/.git-stats, and reading all the commits from the repository itself? Isn't it just redundant?

[IonicaBizau]

Time. Here are my stats since I started using git to now (click on the image to see it bigger):

Really, imagine a tool parsing 18k commits every time you run it... Like I specified before, git-stats runs by default across repositories (not only one).

However, in the case of one repository (git-stats -g), the data comes from the repo history (not from ~/.git-stats).

[h0dgep0dge]

imagine a tool parsing 18k commits every time you run it

And like I said before, it wouldn't need to process all of them at once. It would only process any new commits that had been committed since the last time you ran the program.

[IonicaBizau]

Btw, why do you not like to keep the history in a file? The good point about it is I can just copy the file on another machine I'm working on and see the same stats.

[h0dgep0dge]

I don't have a problem with keeping the history in a file, I have a problem with creating and working off a totally redundant history. Sure, you can copy the file and have the same stats, but you could just copy the repositories and have the same stats.

[h0dgep0dge]

All I'm saying is that I would have done it differently. If you're trying to get me to talk you out of your architecture, how about the fact that it's centralized? I work on several different machines, my PC, a laptop, I sometimes use cloud services when I don't have access to my own machines. As it stands, git-stats wouldn't be able to track all of my work, but it would be able to if it read the data out of the repositories themselves.

[IonicaBizau]

As I mentioned before, this is the way I implemented it–it was the simplest and the cleanest way I could find it (independent of any database and still fast enough). ❇️

Hope you like the new release! 😄