gix fails to decode commit object that git has no trouble with

[bradlarsen]

Duplicates

• I have searched the existing issues

Current behavior 😯

In developing Nosey Parker, which uses gix for picking apart Git repositories, I have discovered a commit object in the wild that gix fails to decode, but that git has no trouble with.

The commit in question is this: boto/boto@c1eddff.

It looks like some funny formatting of the committer timestamp timezone disagrees with gix.

A couple error message log output from my dev copy of Nosey Parker:

WARN git_enumerator{clones/boto/boto}: noseyparker::input_enumerator: Failed to find commit c1eddff4ee3f62b6039f1083651b9118883e7f07: Parse error:
TakeWhileMN at: -700
committer Dan Loewenherz <[email protected]> 1288373970 --700

Fix a bug in the Google Storage Key class that manifested when setting policy in set_contents_from_file

Without this, a TypeError will be thrown if policy is specified.
in section 'HH', at: -700
committer Dan Loewenherz <[email protected]> 1288373970 --700

Fix a bug in the Google Storage Key class that manifested when setting policy in set_contents_from_file

Without this, a TypeError will be thrown if policy is specified.
in section '<name> <<email>> <timestamp> <+|-><HHMM>', at: Dan Loewenherz <[email protected]> 1288373970 --700
committer Dan Loewenherz <[email protected]> 1288373970 --700

Fix a bug in the Google Storage Key class that manifested when setting policy in set_contents_from_file

Without this, a TypeError will be thrown if policy is specified.
in section 'author <signature>', at: author Dan Loewenherz <[email protected]> 1288373970 --700
committer Dan Loewenherz <[email protected]> 1288373970 --700

Fix a bug in the Google Storage Key class that manifested when setting policy in set_contents_from_file

Without this, a TypeError will be thrown if policy is specified.

WARN git_enumerator{clones/boto/boto}: noseyparker::input_enumerator: try_find result: Ok(Some(Data { kind: Commit, data: [116, 114, 101, 101, 32, 48, 97, 56, 53, 49, 100, 55, 97, 50, 97, 54, 54, 48, 56, 52, 97, 98, 49, 48, 53, 49, 54, 99, 52, 48, 54, 97, 52, 48, 53, 100, 49, 52, 55, 101, 57, 55, 52, 97, 100, 10, 112, 97, 114, 101, 110, 116, 32, 51, 49, 51, 53, 48, 102, 52, 102, 48, 102, 52, 53, 57, 52, 56, 53, 101, 102, 102, 50, 49, 51, 49, 53, 49, 55, 101, 51, 52, 53, 48, 99, 102, 50, 53, 49, 102, 54, 102, 97, 10, 97, 117, 116, 104, 111, 114, 32, 68, 97, 110, 32, 76, 111, 101, 119, 101, 110, 104, 101, 114, 122, 32, 60, 100, 108, 111, 101, 119, 101, 110, 104, 101, 114, 122, 64, 103, 109, 97, 105, 108, 46, 99, 111, 109, 62, 32, 49, 50, 56, 56, 51, 55, 51, 57, 55, 48, 32, 45, 45, 55, 48, 48, 10, 99, 111, 109, 109, 105, 116, 116, 101, 114, 32, 68, 97, 110, 32, 76, 111, 101, 119, 101, 110, 104, 101, 114, 122, 32, 60, 100, 108, 111, 101, 119, 101, 110, 104, 101, 114, 122, 64, 103, 109, 97, 105, 108, 46, 99, 111, 109, 62, 32, 49, 50, 56, 56, 51, 55, 51, 57, 55, 48, 32, 45, 45, 55, 48, 48, 10, 10, 70, 105, 120, 32, 97, 32, 98, 117, 103, 32, 105, 110, 32, 116, 104, 101, 32, 71, 111, 111, 103, 108, 101, 32, 83, 116, 111, 114, 97, 103, 101, 32, 75, 101, 121, 32, 99, 108, 97, 115, 115, 32, 116, 104, 97, 116, 32, 109, 97, 110, 105, 102, 101, 115, 116, 101, 100, 32, 119, 104, 101, 110, 32, 115, 101, 116, 116, 105, 110, 103, 32, 112, 111, 108, 105, 99, 121, 32, 105, 110, 32, 115, 101, 116, 95, 99, 111, 110, 116, 101, 110, 116, 115, 95, 102, 114, 111, 109, 95, 102, 105, 108, 101, 13, 10, 13, 10, 87, 105, 116, 104, 111, 117, 116, 32, 116, 104, 105, 115, 44, 32, 97, 32, 84, 121, 112, 101, 69, 114, 114, 111, 114, 32, 119, 105, 108, 108, 32, 98, 101, 32, 116, 104, 114, 111, 119, 110, 32, 105, 102, 32, 112, 111, 108, 105, 99, 121, 32, 105, 115, 32, 115, 112, 101, 99, 105, 102, 105, 101, 100, 46] }))

The commit as dumped by git:

% git show --format=raw c1eddff4ee3f62b6039f1083651b9118883e7f07
commit c1eddff4ee3f62b6039f1083651b9118883e7f07
tree 0a851d7a2a66084ab10516c406a405d147e974ad
parent 31350f4f0f459485eff2131517e3450cf251f6fa
author Dan Loewenherz <[email protected]> 1288373970 --700
committer Dan Loewenherz <[email protected]> 1288373970 --700

    Fix a bug in the Google Storage Key class that manifested when setting policy in set_contents_from_file

    Without this, a TypeError will be thrown if policy is specified.

diff --git a/boto/gs/key.py b/boto/gs/key.py
old mode 100755
new mode 100644
index d9ac254b..310a7092
--- a/boto/gs/key.py
+++ b/boto/gs/key.py
@@ -163,6 +163,8 @@ class Key(S3Key):
         just overriding/sharing code the way it currently works).
         """
         provider = self.bucket.connection.provider
+        if headers is None:
+            headers = {}
         if policy:
             headers[provider.acl_header] = policy
         if hasattr(fp, 'name'):

Expected behavior 🤔

gix should successfully decode this commit object data to match the behavior of git.

Steps to reproduce 🕹

1. Clone https://github.com/boto/boto
2. Using gix, open the repository, get the repository's odb, and then use odb.find_commit(ObjectId::from_hex("c1eddff4ee3f62b6039f1083651b9118883e7f07".as_bytes()))
3. You will get an Err result, when the commit should probably decode successfully instead.

I tested this with gix = { version = "0.50", features = ["max-performance"] } and gix-object = { version = "0.33", features = ["verbose-object-parsing-errors"] }.

[Byron]

Thanks a lot for the detailed report!

I truly wonder what software is used to produce these commits :). In any case, gix has to read them and I will make sure of it soon.

[Byron]

This will be fixed with the next release :)!

[Byron]

This issue should be resolved with the latest release.

[bradlarsen]

Thank you so much!