Silent false success when git is not present

[thesmiley1]

When git cannot be found in PATH and the user runs commitlint with parameters to read from the git log, commitlint exits with status 0 and no output.

Expected Behavior

When git is needed and cannot be found, commitlint should exit with a non-zero status and print an error.

Current Behavior

When git cannot be found in PATH, commitlint exits with status 0 and no output.

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

Checking the exit status of git would be a good idea. That takes place in git-raw-commits; I will open a PR there soon.

Steps to Reproduce (for bugs)

1. Go to repo
   cd /path/to/repo
2. Add a commit with a bad message
   touch foo && git add foo && git commit --no-verify -m 'Bad Commit Msg'
3. Remove git from PATH somehow, e.g.
   sudo mv /usr/bin/git /usr/bin/git.bak
4. Run commitlint; note zero exit status and no output
   commitlint --from HEAD~1
5. Don't forget to put git back if needed, e.g.
   sudo mv /usr/bin/git.bak /usr/bin/git

Context

The reproduction steps above may make this seem like a convoluted edge case, but it is not too difficult to run into.

I encountered this bug when setting up CI jobs to run in an alpine linux container. The repository is made available to the container via a bind mount and git is not installed by default. I didn't realize at first that git was missing and was confused by commitlint succeeding when it should not.

Another way a dev could be affected by this is if git is uninstalled for some reason (accidental, troubleshooting, etc).

Your Environment

Executable	Version
commitlint --version	@commitlint/[email protected]
git --version	git version 2.28.0
node --version	v14.11.0

[escapedcat]

Wonder if we should tag this and #2118 with something like dep-bug or something similar. Or maybe these bugs should be opened in the related repo in the first place?

[thesmiley1]

Wonder if we should tag this and #2118 with something like dep-bug or something similar. Or maybe these bugs should be opened in the related repo in the first place?

I missed this comment when it was made. I'm not sure to what extent it was directed at me, but I will drop my .02.

Since the bug directly affects users of commitlint (and that is how it was found), I think a bug report here is definitely appropriate.

That isn't to say there shouldn't also be a bug report in the conventional-changelog repo where the git-raw-commits package (and source of this bug) lives. I eschewed doing that since since everything lives under the same organization. If needed I could open a bug report there as well, from the perspective of a consumer of the package rather than a user of commitlint.

[iamscottcab]

I've been thinking about this for a few days. If the issue is definitely in git-raw-commits then I'd rather patch the source of the bug than just patch it here? Given that might be a useful fix for others and we consume dependencies so we don't have to re-write everything all time.

I only would only recommend not doing it here if the fix is specific to commitlint but I'm guessing this could be a downstream problem for other packages that use git-raw-commits.