Gitinspector ignore one of two commits in the same interval

[ghardoim]

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]

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]

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]

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]

Hi @adam-waldenberg.

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

That's help you?

[adam-waldenberg]

Hi @ghardoim.

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

[ghardoim]

Hi @adam-waldenberg

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

[adam-waldenberg]

@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]

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]

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]

Bumping to 0.5.0 milestone.