Closed auscompgeek closed 7 years ago
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...
Currently, git-source-track depends on a constant value for
core.abbrev
between developers. (This typically means thatcore.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.