Gitinspector ignore one of two commits in the same interval

ejwa / gitinspector

:bar_chart: The statistical analysis tool for git repositories

GNU General Public License v3.0

2.38k stars 328 forks source link

Gitinspector ignore one of two commits in the same interval #179

Open ghardoim opened 6 years ago

ghardoim commented 6 years ago

I'm running the following comand to find two commits that I know they exist, but the gitinspector don't find one of them.

python "gitinspector.py" -f** --since=2018-05-07-15:02:00 --until=2018-05-07-15:03:00 "path"

In this interval there are two commits: one at --since=2018-05-07-15:02:00 --until=2018-05-07-15:02:10 and the other at --since=2018-05-07-15:02:20 --until=2018-05-07-15:02:40.

But when I run the gitinspector to catch boths commits, it find only the second commit.

What am I doing wrong?

adam-waldenberg commented 6 years ago

Hi @GHardoim.

Interesting. How does git itself react if you do a shortlog with the very same --since / --until flags ?

What version are you using ? Please use the latest stable release (not the master version).

ghardoim commented 6 years ago

Hi @adam-waldenberg, thanks for your answer!

I ran the commands git log and shortlog and both found all two commits in this interval. I believe it's something with the parameter -f**, because:

I used the releases v0.4.4, v0.4.3 and v0.4.2 with and without this parameter and they didn't find the two commits.
In the release v0.4.1, who doesn´t have the –f** parameter, I added the extensions manually with –file-types=EXTENSIONS parameter and then it found the two commits in the interval.
I tried to use –file-types=EXTENSIONS with the newer releases (>=v0.4.2)and the problem still occurs with these. So, maybe, version v0.4.2 introduced a bug.

So, I think I could isolate the problem, but if it is true, I have not identified a solution yet. Does it make sense to you?

adam-waldenberg commented 6 years ago

Hi @GHardoim.

So it seems perhaps that the introduction of "**" might have broken something. Could you do a "git bisect" run on the "extra-release/0.4.x" branch ? This should allow you to find the exact commit that broke the functionality.

ghardoim commented 6 years ago

Hi @adam-waldenberg.

I executed the bisect and it found this commit aeb9ad69f93f480fa7ac1df231a9864b9c386369 as the first bad commit.

That's help you?

adam-waldenberg commented 6 years ago

Hi @GHardoim.

Thank you. Yes, that threading code introduced a few problems.... Can you test the master version ? There was a fix introduced in 6d77989e341e043c9a7f09757000d75701b32d84 - it may cover this problem...

ghardoim commented 6 years ago

Hi @adam-waldenberg

I tested the master version with the commit that you said but still not working

adam-waldenberg commented 6 years ago

@GHardoim OK... So we probably have some logic error introduced with filtering and the threaded version of changes.py. I will look into it.

ghardoim commented 6 years ago

Hi @adam-waldenberg It's me again Let me ask you a question...

I have a bash script that calls the gitinspector to a large number of repositories in a repetitive way (day per day, since the begin of year) and at some point, while my script keeps calling, the gitinspector does not work anymore. If I call it thus, is there any chance of an overload occurring?

adam-waldenberg commented 6 years ago

Hi @GHardoim If you start each instance recursively (with &) - yes. If you run gitinspector synchronously I don't think you should have a problem though.

adam-waldenberg commented 3 years ago

Bumping to 0.5.0 milestone.