Feature to "get the pulse" of a project based on number of lines changed with x-axis as time

[MikeTheSapienV2]

Zuerst, viele danke for this project of yours!

• Is your feature request related to a problem?
  No

• Describe the solution you'd like.
  What if the user could plot a 2D graph of a git project's activity in terms of the number of lines changed per period?
  The user would maybe add a date range and the period kind: daily, weekly, monthly, and so on for this feature, and the binary would then spit out a CSV file indicating the number of lines changed in the given period for the y-axis, and the period in a sequential manner would be in the x-axis.

  The created CSV file would then be used by the user as an input to a plotting library of their choosing.

• Describe alternatives you've considered.
  None yet.

• Add any other context about the feature request.
  This can be done easily with any scripts, Powershell, Python, or a bash script for UNIX along with already existing git flags. But by any chance, you might be interested in integrating this proposed feature to your project.

  I can implement the code myself and make pull requests by following your guidelines on how you think the codes should be implemented if you'd like.

[alex289]

Hey, thanks for your interest in this project.

So in summary you want a csv export of line changes in a time range? Im generally not averse for this feature but I would like to keep this cli as simple as possible. The cli should still be focused on just showing data rather than exporting it.

Can you provide some existing solutions and what is missing there what could solved here?

[MikeTheSapienV2]

So in summary you want a csv export of line changes in a time range?

Yes. With the x-axis indicating the period. Maybe it's daily, weekly, monthly, and so on. And the y-axis indicating maybe the number of insertions, or deletions.

Perhaps the CSV file might have the following rows:

period, addition, deletion
day-1, 25, 0
day-2, 40, 16
day-3, 0, 0
day-4, 0, 30
...
day-n, p, q

The cli should still be focused on just showing data rather than exporting it.

It doesn't have to be exactly a CSV file. Maybe the binary would output a JSON data that would be copied and pasted to some graph plotter, maybe something like passing the JSON values into libraries like: Plotting JSON Data with Chart.js

this cli as simple as possible.

Got it. Please do let me know whether my suggestions aren't "simple" additions, as we may have a different perspectives on what "simple" is in your project.

Can you provide some existing solutions and what is missing there what could solved here?

I'd poked around mostly in GitHub gists and StackOverflow posts. It seems to be a fairly sought after solution (see). Most of the solutions I've seen uses UNIX scripting with use of awk, sed, and such, which can't be a solution for Windows users (unless they run it in wsl).

Most of the solutions used git log, along with awk, sed, with bash, i.e. 1, 2, 3

If it'll be too complicated or irrelevant to be added on your project, I'm thinking of simply using git diff --shortstat "@{1 day ago}", as I've seen here with some scripting language, looping on $1..n$ where $n$ is the user's selected number of days back, while doing some basic arithmetic to isolate the number of changes per day, or per week, and so on.

[alex289]

Hey, sorry for the late answer. I like the idea of this. I would recommend a flag like --export to access this functionality.

If you want you can go for it and make a pull request 😄

[MikeTheSapienV2]

Wunderbar! Kein Problem if it's late. We all have our own different responsibilities, contexts, happenings in life, and so on.

Perhaps a future improvement would be placing the result into the user's machine's system clipboard. I'll just have to spend time to review how the helix guys and gals does it.

---

It's my first time encountering git2, upon reviewing this repo's code base, and so I may be implementing an inefficient or ugly solution to address this feature.

On reading the documentation of git2, I've found out the struct git2::DiffStats having methods such as insertions(&self) -> usize and deletions(&self) -> usize which are pertinent information for this "get the pulse" feature.

But to get the aforementioned struct, there has to be some loops one has to go through. To get DiffStats, one has to instantiate git2::Diff. And to get the previous struct, git2::Repository::diff_tree_to_tree() (diff_tree_to_tree) has to be called.

And lastly, diff_tree_to_tree's signature requires some of the arguments: old_tree: Option<&Tree<'>>,
new_tree: Option<&Tree<'>>, which I think can be derived from one of this project's function.

I've read in analyzer.rs the function get_commits<'repo>(), which returns Vec<Commit<'repo>>. And Commit has a method tree() and tree_id() to get the tree's info, and pub fn time(&self) -> Time for the x-axis of this feature.

As an overview:

1. get_commits()
2. do some loops to get trees between commits
3. get diffs between trees in (2)
4. get diff stats from (3)
5. package all the information on some struct maybe for time in commits from (1) and stats from (4)

Do you think this is a good initial subroutine flow?

---

Is it okay if I ask such questions or expect such interactions? I'm fairly new to contributing to open source. So please do let me know if I'm doing something wrong.

[MikeTheSapienV2]

I'm sorry, I just found out about get_commit_stats() in analyzer.rs, which returns DiffStats. I marked my previous comment as outdated. I considered deleting it, but maybe it's better to be transparent about my mistake so others might also see it and improve themselves.

I'll re-review the code base of this project and will get back in a couple of days.

---

But still, my previous question, is it okay if I ask such questions or expect such interactions? I'm fairly new to contributing to open source. So please do let me know if I'm doing something wrong.

If you think this is too much commenting and only want the PR, I can stop commenting.

[alex289]

No of course. I will try my best to help 🙂

[MikeTheSapienV2]

Do you prefer the "exporting of project pulse by a user" functionality (added "by a user" based on discussions here, to those reading these without context) be contained in a single function and without touching other parts of the code?

With this functionality, access to/taking of git2::Time is needed, and it's already done in analyzer::show_coding_habits(), if you prefer to contain my proposals in a single function without touching others, then I think I'd simply run again:

    let mut commit_times = Vec::new();

    for commit in commits {
        …
        commit_times.push(commit.time().seconds());
    }

But, if you prefer to avoid repeating some processing (just a tiny bit), taking of the commit.time() would then have to be done outside of analyzer::show_coding_habits(), consequently editing the function signature of show_coding_habits().

PS. Edited for a bit of explicitness and use of punctuations.