-
Notifications
You must be signed in to change notification settings - Fork 385
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
feat: add support for .gitignore #1908
base: master
Are you sure you want to change the base?
Conversation
@fmeum can you confirm if adding this to the gazelle core is something we'd like to do? If so are there preferences for which library to use vs manual? |
How is this different from using 'gazelle:exclude' directives? |
People won't want to copy+paste gitignore files into BUILD files...? |
Functionally gitignore also works a bit different with things like |
I kind of like this as it reduces the amount of Gazelle-specific configuration. I don't know which library is best, but we should definitely use one rather than roll our own. |
I agree we should use a real library and not try to re-implement gitignore logic, otherwise we'll just end up with a never-ending stream "it doesn't work like git" bugs. The |
FWIW I've also tried other libraries which all had issues in the aspect gazelle extensions:
Those both also seem to be unmaintained. Others I have not tried seem to also be unmaintained and many look too simple or slow: |
7ed05a4
to
610ea22
Compare
698d1b1
to
52d7986
Compare
name = "rename_%s_%s" % (TESTS[i], j), | ||
srcs = [TEST_GEN_FILES_IN[i][j]], | ||
outs = [TEST_GEN_FILES_OUT[i][j]], | ||
cmd = "cp $< $@", |
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.
Something here is not working on windows where this genrule is either not being generated or is not dropping the .test-
from the path, I assume because of slashes.
Anyone see anything wrong here? Or have a windows box to debug it more?
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.
I gave up and ignored this test on windows for now. I confirmed it is renaming the files but the .test-*
files are still visible. I assume this is a windows+sandboxing issue?
ed09b76
to
0f82486
Compare
This reduces the noise a lot when adding more libraries such as in #1908 **What type of PR is this?** > Other **What package or component does this PR mostly affect?** > all **What does this PR do? Why is it needed?** **Which issues(s) does this PR fix?** Fixes # **Other notes for review**
This looks great to me, @fmeum wdyt? |
55f9844
to
cce54f9
Compare
entParts[len(entParts)-1] = base | ||
|
||
// Skip git-ignored when the gitignore option is enabled. | ||
if wc.isGitIgnored(entParts, ent.IsDir()) { |
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.
Note this is its own conditional and not embedded within isExcluded
for a few reasons:
- I don't think .gitignore can exclude the parent directory it is within the way
# gazelle:exclude *
can (that is the reason we must invokeisExcluded
both above and within thisfor
loop). isGitIgnored
requires the path as[]string
and needs to knowIsDir()
, I don't think we should overrideisExcluded
with more params
… gazelle feature implementation (#6873) This aligns the implementation more with what I'm trying to merge into gazelle: bazel-contrib/bazel-gazelle#1908 There are no user facing changes here but the implementation is simpler and should improve performance for many reasons: * the .gitignore files are only `os.Open`ed once per directory (not per directory * per language) * the .gitignore files are only parsed once instead of once per gazelle language * the .gitignore patterns are only executed once because it is done within the (patched) gazelle walk * .gitignore-d directories are not recursed into at all because they are filtered in the gazelle fs walk * ... --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: 27fe8377ca89de91d3c95105ab37adea9347e6ab
… gazelle feature implementation (#6873) This aligns the implementation more with what I'm trying to merge into gazelle: bazel-contrib/bazel-gazelle#1908 There are no user facing changes here but the implementation is simpler and should improve performance for many reasons: * the .gitignore files are only `os.Open`ed once per directory (not per directory * per language) * the .gitignore files are only parsed once instead of once per gazelle language * the .gitignore patterns are only executed once because it is done within the (patched) gazelle walk * .gitignore-d directories are not recursed into at all because they are filtered in the gazelle fs walk * ... --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: 27fe8377ca89de91d3c95105ab37adea9347e6ab
… gazelle feature implementation (#6873) This aligns the implementation more with what I'm trying to merge into gazelle: bazel-contrib/bazel-gazelle#1908 There are no user facing changes here but the implementation is simpler and should improve performance for many reasons: * the .gitignore files are only `os.Open`ed once per directory (not per directory * per language) * the .gitignore files are only parsed once instead of once per gazelle language * the .gitignore patterns are only executed once because it is done within the (patched) gazelle walk * .gitignore-d directories are not recursed into at all because they are filtered in the gazelle fs walk * ... --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: 27fe8377ca89de91d3c95105ab37adea9347e6ab
… gazelle feature implementation (#6873) This aligns the implementation more with what I'm trying to merge into gazelle: bazel-contrib/bazel-gazelle#1908 There are no user facing changes here but the implementation is simpler and should improve performance for many reasons: * the .gitignore files are only `os.Open`ed once per directory (not per directory * per language) * the .gitignore files are only parsed once instead of once per gazelle language * the .gitignore patterns are only executed once because it is done within the (patched) gazelle walk * .gitignore-d directories are not recursed into at all because they are filtered in the gazelle fs walk * ... --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: 27fe8377ca89de91d3c95105ab37adea9347e6ab
Based on aspect-build/aspect-cli#755, what do you expect to be the use case for this if we can't enable it by default due to performance issues? It's surprising to me that |
I was suggesting it should be disabled by default because that is the ideal use case for both "correctness" and performance (although performance is only really a concern in very large projects globbing on hundreds of thousands of files). However enabling it by default is probably a better initial experience for most projects so I'm fine with that as well. Longer explanation, imo... The ideal use case is when bazelignore specifies everything bazel should ignore, and gitignore specifies everything git should ignore. Those are not always 1-1... sometimes bazel might need to process things that are git ignored, very often things such as IDE config are in git but should be ignored by bazel etc. In reality the more common use case is projects use gitignore and then (partially) duplicate that in This feature would remove the need for many of those |
Gitignore and generation-mode are both generic gazelle config and should require no code in plugins. Note that both of these are currently patched into gazelle while waiting for PRs which will allow the removal of all aspect code: bazel-contrib/bazel-gazelle#1921 bazel-contrib/bazel-gazelle#1908 --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: cdfe6690ff0ab2584e429419612cc32e94c6b379
Gitignore and generation-mode are both generic gazelle config and should require no code in plugins. Note that both of these are currently patched into gazelle while waiting for PRs which will allow the removal of all aspect code: bazel-contrib/bazel-gazelle#1921 bazel-contrib/bazel-gazelle#1908 --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: cdfe6690ff0ab2584e429419612cc32e94c6b379
Gitignore and generation-mode are both generic gazelle config and should require no code in plugins. Note that both of these are currently patched into gazelle while waiting for PRs which will allow the removal of all aspect code: bazel-contrib/bazel-gazelle#1921 bazel-contrib/bazel-gazelle#1908 --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: cdfe6690ff0ab2584e429419612cc32e94c6b379
Gitignore and generation-mode are both generic gazelle config and should require no code in plugins. Note that both of these are currently patched into gazelle while waiting for PRs which will allow the removal of all aspect code: bazel-contrib/bazel-gazelle#1921 bazel-contrib/bazel-gazelle#1908 --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: cdfe6690ff0ab2584e429419612cc32e94c6b379
Gitignore and generation-mode are both generic gazelle config and should require no code in plugins. Note that both of these are currently patched into gazelle while waiting for PRs which will allow the removal of all aspect code: bazel-contrib/bazel-gazelle#1921 bazel-contrib/bazel-gazelle#1908 --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: cdfe6690ff0ab2584e429419612cc32e94c6b379
Gitignore and generation-mode are both generic gazelle config and should require no code in plugins. Note that both of these are currently patched into gazelle while waiting for PRs which will allow the removal of all aspect code: bazel-contrib/bazel-gazelle#1921 bazel-contrib/bazel-gazelle#1908 --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: cdfe6690ff0ab2584e429419612cc32e94c6b379
Gitignore and generation-mode are both generic gazelle config and should require no code in plugins. Note that both of these are currently patched into gazelle while waiting for PRs which will allow the removal of all aspect code: bazel-contrib/bazel-gazelle#1921 bazel-contrib/bazel-gazelle#1908 --- ### Changes are visible to end-users: no ### Test plan - Covered by existing test cases GitOrigin-RevId: cdfe6690ff0ab2584e429419612cc32e94c6b379
Rebased. @fmeum any updates with getting this reviewed/merged? |
What type of PR is this?
What package or component does this PR mostly affect?
What does this PR do? Why is it needed?
Allow users to opt-in to respecting the gitignore when collecting files for gazelle extensions to consume.
While bazel can access git-ignored files many repositories manually exclude git-ignored content by not including it in source file lists or globs in BUILDs or by duplicating the git-ignore entries as
# gazelle:exclude
.Ideally users would put all bazel ignored content in
.bazelignore
but without glob support that is often not done.This should remain opt-in for repositories wanting it but by default bazel can access git-ignored content so gazelle should as well.
Which issues(s) does this PR fix?
Fixes #1166
Other notes for review