The regex in StatusEntry::try_from() was mistaken parsing status lines for files with spaces in such a way to discard the first word in the path name. This attempts to make that less likely by making the regex more specific, but I don't think it's really unavoidable without completely reworking this part of the code to be less flexible. eg if we parsed each of the 1/2/u statuses separately, then we could be more specific about how many fields we need to match/capture for each option.
I suspect that this issue was already rare, and that this fix will make it even moreso. Given that, I feel like a more robust/complex fix probably isn't warranted. With this fix, files like "r101 project.txt" or "Coffee notes.txt" will work, but "R101 project.txt" or "coffee notes.txt" ("R101" looks like a "change score", and "coffee" is a valid hex value.) (Edit: 🤦 coffee is not a "hex word"; c0ffee is, though.)
The options that come to mind to tighten this up further:
parse each 1/2/u status separately, making field counts and patterns more discrete
require a minimum number of chars in an object ID (on my Mac, the longest "hex word" in /usr/share/dict/words is 7 chars, so requiring at least 8 chars in an OID would eliminate "coffee"-style false positives)
The regex in
StatusEntry::try_from()was mistaken parsing status lines for files with spaces in such a way to discard the first word in the path name. This attempts to make that less likely by making the regex more specific, but I don't think it's really unavoidable without completely reworking this part of the code to be less flexible. eg if we parsed each of the 1/2/u statuses separately, then we could be more specific about how many fields we need to match/capture for each option.I suspect that this issue was already rare, and that this fix will make it even moreso. Given that, I feel like a more robust/complex fix probably isn't warranted. With this fix, files like "r101 project.txt" or "Coffee notes.txt" will work, but "R101 project.txt" or "coffee notes.txt" ("R101" looks like a "change score", and "coffee" is a
validhex value.) (Edit: 🤦coffeeis not a "hex word";c0ffeeis, though.)The options that come to mind to tighten this up further: