- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 935
diff incorrectly populates submodule blobs #891
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
Labels
Comments
The initial issue is tracked at tails: https://redmine.tails.boum.org/code/issues/16862 |
Thanks a lot for this fantastic issue! I could reproduce it and hope someone can dig in deeper for a PR with a fix. |
Byron
pushed a commit
that referenced
this issue
Oct 21, 2019
asharov
pushed a commit
to asharov/git-hammer
that referenced
this issue
Oct 28, 2019
By default, git diff includes entries for submodules in its output. This breaks when trying to extract information from such a file since the submodule directory is not in fact a file known to git. This may be related to a GitPython issue: gitpython-developers/GitPython#891 But for git-hammer, the sensible course of action seems to be ignoring submodules. They are not code in the main repository, and if their code should be in a project, the actual repository can be included. So add to diff the option ignore-submodules that causes it to skip submodules. Also add a unit test that creates a submodule in the test repository and verifies that git-hammer works correctly on it.
Hi, @hefee reported elsewhere that this bug is fixed in 3.0.5. I suppose that's thanks to #947. Shall this issue be closed? |
Ack we can close this one, because of #974 got merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The blobs returned by diff are somehow different that the blobs returned by
commit.tree/path
for submodule blobs. E.g. if I try to create a IndexEntry from a blob it fails with a ValueError, when using the blob from diff. As you see I added an assert (line 28) to make sure, that I really access the same blob!I can run successfully:
but fails for:
Here is my test script (/tmp/test.py)
The text was updated successfully, but these errors were encountered: