-
-
Notifications
You must be signed in to change notification settings - Fork 933
Assert fails in GitPython 0.3.5 comparing FETCH_HEAD and branches actually fetched #232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
You can set GIT_PYTHON_TRACE=full in your shell to see all the commands that git-python runs in the background. A quick look revealed that its probably only running git-python version 0.3.3 to 0.3.4 don't have this assertion at all and should therefore just work for you. The only way I think this can be fixed is if I can reproduce it, so let me post the information here that I put in the referenced issue: I would be glad if you could help me to reproduce this issue - either by providing me with steps to do it myself or by getting access to the data involved. The latter would be each line in Thank you. |
Hi Byron, I see the assertion in 0.3.3 here: It's also in a similar place in 0.3.4 so this would also fail for me. How do I get the lines in my_progress_handler? And please let me know how I can send you this info. |
Are you able to use a custom version of git-python in your setup ? If so, I could make a temporary branch that will contain code to write this information to files. These files you could just attach here by dropping them into the issue (or make a gist). |
I can use a custom version of git-python in the meantime, yes, so I can send you those files. The repo is not publicly accessible so if possible I'd like to send these files to you privately. |
Alright, let's do that. You could send me a private message on github with download links. Additionally, you could find-and-replace common portions of both files to obfuscate them, as long as said obfuscation is consistent within each file, and across both files. After all, I don't want your secrets either :). |
Oh, and I will make a post here once the branch is ready. |
You will find a git-python version able to write the respective information in this branch. Please check the commit message for more information on where the debug data can be found. Last but not least, you can watch the archived live-stream of the work done on the issue so far on youtube. |
@domino14 Release v0.3.6 is due this week, and I would be glad if I could provide a fix to this issue in it. For you it should be as simple as running your testcase/code with the provided branch and send me the files. Feel free to send them by e-mail. Thank you ! |
sent you an email with the files, thanks! On Mon, Jan 19, 2015 at 5:00 AM, Sebastian Thiel [email protected]
|
Thank you !
|
When the problem started there was only 1 line missing in the progress
On Mon, Jan 19, 2015 at 12:02 PM, Sebastian Thiel [email protected]
|
Great ! There are two different branches for parsing process output, and the one using |
…is read. This simplification should improve performance and remove issues like those in #232. NOTE: Debug code is still contained here
@domino14 Please have a look at the latest state on our issue-related branch, as it contains simplifications which should make your case work natively. |
…git.cmd There have been rather obvious errors in there, as we forgot to unregister the filehandles. Now we will read from a buffer ourselves, which should be faster and ideally, doesn't lead to spurious errors anymore. Related to #232
@domino14 Please also try the latest master branch, as it contains a greatly improved |
Make sure we keep the improvements made to fetch and pull Relates to #232
Please note that I have merged improvements made to the issue-related branch into master, without the debug portions. |
Hi Byron, thanks and your live streams are pretty cool - good idea. The current master works without throwing any exceptions. Thanks for looking at this!! |
Awesome, I am happy to hear that, in every which way ! |
gitpython-developers/GitPython#232 presumably caused due to too many branches
Stack trace:
I wrote a script to parse the two things that it is trying to compare, from the assert output. FETCH_HEAD right now has 813 lines. The output of git fetch, when I run it manually on the command line (I have not been able to figure out exactly what command it is running, but I'm assuming it's
git fetch --all -v
- is this correct?) has also 813 lines if you ignore the first two lines:Fetching origin
andFrom github.com:org/repo
However, the very last 4 branches in FETCH_HEAD are missing in the GitPython fetch output, the last of which is this line:
a3a81646dd65dfa4b4412c0f3a5fd4183cbaa2e5 not-for-merge branch 'zendesk' of github.com:org/repo
It can't find the matching line in the fetch output (or for the previous 3):
= [up to date] zendesk -> origin/zendesk
Even though I see the above lines when I do
git fetch --all -v
, I don't see the last 4 lines in the GitPython assert output. Let me know if you need more info. Is there possibly some length limit? I'm using git 1.8.3.4.BTW I was using GitPython==0.3.2.RC1 prior to this and it was still failing an assertion, although I'm not sure the assertion was exactly the same.
The text was updated successfully, but these errors were encountered: