In some places, git-xargs is forced to fall back to reading the error message value from GitHub's API responses, since the GitHub API can be inconsistent in what headers, status codes, etc it actually returns under various conditions.
Per this comment we should refactor all such instances, of error messages that we're keying off to determine some runtime status, into a new constants.go file so that they will be Easier to Change in the future.
In some places, git-xargs is forced to fall back to reading the error message value from GitHub's API responses, since the GitHub API can be inconsistent in what headers, status codes, etc it actually returns under various conditions.
Per this comment we should refactor all such instances, of error messages that we're keying off to determine some runtime status, into a new
constants.gofile so that they will be Easier to Change in the future.