git-source-track depends on core.abbrev=7
Closed this issue · 12 comments
Currently, git-source-track depends on a constant value for core.abbrev between developers. (This typically means that core.abbrev has to be exactly 7.)
This leads to git-source-track claiming that every file is out of sync when a user sets core.abbrev to 12 (for example) in their git config.
Ha, nice, didn't realize it was a setting. I guess one could set this per repository using .gitattributes? Or perhaps it could force it to something, or do prefix matching instead...
Luckily repo git configs override user configs (which in turn override system-wide configs), so the workaround is simple enough. It's arguably not a good solution though.
Getting the full commit hashes from the upstream repo and checking the prefix would probably be a nice solution to this.
I'm not actually able to duplicate this bug, it seems to work fine when I set core.abbrev to 12. Can you give a specific example?
Also note that with robotpy-wpilib, just about every file IS old. However, pynetworktables is mostly up to date with ntcore.
Oh, I found it. It's when the value in the file is invalid.
Fixed, let me know if that works for you. If so, I'll push it out to pypi.
Looks good, thanks!
I don't think the latest version is on pypi, and it currently breaks with the .gittrack config file in robotpy-wpilib.
It'll be there in 5 minutes, sorry about that.
Uploaded.
Thanks, confirmed working. Now to get to work... ;)
Awesome, I'm almost done with fixing up HAL...