-
Notifications
You must be signed in to change notification settings - Fork 951
chore(git): find the closer .git #4588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
chore(git): find the closer .git #4588
Conversation
The previous method preferred finding `.git` files over `.git/` directories. That doesn't work if, for some reason, the user a `.git/` directory inside the repo with commitlint and that repo path is nested inside another git repo. Ignoring the fact that this isn't a standard use of git, it still works, and can be trivially supported by comparing the path lengths. Priority: Low Tests: None, but there were none in @commitlint before this, either. Risk: Low
Add a unit test showing the previous change works as expected.
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR fixes a bug in the .git discovery logic to prefer the closer .git path when both a file and directory are found. This addresses an edge case where a git repository with commitlint is nested inside another git repository.
Key Changes:
- Modified the
searchDotGitfunction to compare path lengths when both.gitfile and directory are found - Added comprehensive test coverage for the new logic including edge cases for nested repositories and submodules
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
@commitlint/top-level/src/index.ts |
Added logic to compare path lengths and return the closer .git when both file and directory exist |
@commitlint/top-level/src/index.test.ts |
Added comprehensive test suite with 4 tests covering basic functionality, nested repos, submodules, and missing .git scenarios |
@commitlint/top-level/package.json |
Added @commitlint/test as a dev dependency for testing utilities |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Return whichever is deeper (closer to cwd) by comparing path lengths | ||
| return foundFile.length > foundDir.length ? foundFile : foundDir; |
Copilot
AI
Dec 18, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While path length comparison works for determining proximity in typical cases, it's fragile and relies on filesystem conventions. Consider using path segment counting or explicit path comparison methods for more robust and maintainable code. For example, comparing foundFile.split(path.sep).length vs foundDir.split(path.sep).length would make the intent clearer and be more resilient to edge cases.
| // Return whichever is deeper (closer to cwd) by comparing path lengths | |
| return foundFile.length > foundDir.length ? foundFile : foundDir; | |
| // Return whichever is deeper (closer to cwd) by comparing path segment counts | |
| const fileDepth = path.resolve(foundFile).split(path.sep).length; | |
| const dirDepth = path.resolve(foundDir).split(path.sep).length; | |
| return fileDepth > dirDepth ? foundFile : foundDir; |
| const foundDir = await findUp(".git", { cwd, type: "directory" }); | ||
|
|
||
| if (foundFile && foundDir) { | ||
| // Return whichever is deeper (closer to cwd) by comparing path lengths |
Copilot
AI
Dec 18, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment says "whichever is deeper (closer to cwd)" but the code returns the longer path. In the context of file paths, "deeper" typically means more nested (more path segments), not a longer string. This mismatch between comment and implementation could be confusing.
| // Return whichever is deeper (closer to cwd) by comparing path lengths | |
| // Return whichever has the longer path string |
|
Hey, thanks! Have a look at copilots feedback please. And adjust your commit message ;)
|
Description
return the shorter (closer to cwd) path rather than preferring .git files to .git folders.
Motivation and Context
The previous method preferred finding
.gitfiles over.git/directories. That doesn't work if, for some reason, the user a.git/directory inside the repo with commitlint and that repo path is nested inside another git repo. Ignoring the fact that this isn't a standard use of git, it still works, and can be trivially supported by comparing the path lengths.Fixed bug when running commitlint as part of pre-commit from git repo nested inside another git repo.
Usage examples
n/a
How Has This Been Tested?
Created unit test. Ran
yarn test @commitlint/top-levelTypes of changes
Checklist: