gitinspector
gitinspector copied to clipboard
ejwa
Gitinspector ignore one of two commits in the same interval
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?
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).
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?
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.
Hi @adam-waldenberg.
I executed the bisect and it found this commit aeb9ad69f93f480fa7ac1df231a9864b9c386369 as the first bad commit.
That's help you?
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...
Hi @adam-waldenberg
I tested the master version with the commit that you said but still not working
@GHardoim OK... So we probably have some logic error introduced with filtering and the threaded version of changes.py. I will look into it.
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?
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.