Skip to content
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

Attempt auto-generated files being hidden by default #421

Merged
merged 6 commits into from
Aug 29, 2022

Conversation

ivantsepp
Copy link
Contributor

This PR introduces a new feature to auto hide autogenerated files. It builds upon the recent commit of being able to collapse files (c1ffa46). The idea is to parse out autogenerated file patterns from .gitattributes (link) and automatically collapse matching files in the UI.
Hound

Note
This is a PR just to spark discussion! I'm not sure what the best approach is as there are many options. We can ask questions like:

  • automatically exclude these files in excluded_files.json (should speed up searches as these files aren't indexed)
  • add a button to hide and reveal autogenerated files
  • allow this list to be expressed in configuration

Thoughts on a feature like this? And what would the best approach be? Thanks!

@salemhilal
Copy link
Contributor

I love this idea! Here are some initial thoughts:

  • I really like the idea of parsing out .gitattributes. linguist-generated annotations are already used to do essentially the same thing in Github, and mirroring that behavior here seems intuitive.
  • I am not sure if it makes sense to put this behavior behind a config param or not. I'm erring towards no, at least unless it becomes an issue for someone.
  • I think it might be a good idea to still index these files, but leave them collapsed (similar behavior to Github). Having files be excluded entirely feels to me like something you'd want to opt into separately. I don't usually want to see the output of generated files, but I do on occasion.

That's all my first pass on the details of implementation. Generally though, this feels like a feature I didn't realize I needed. I'm gonna read through the PR now.

ExcludeDotFiles: repo.ExcludeDotFiles,
SpecialFiles: wd.SpecialFiles(),
AutoGeneratedFilePatterns: wd.AutoGeneratedFilePatterns(vcsDir),
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, you swapped the order of this block so that we don't create opt if there's an error pulling?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah i swapped it because i needed wd.PullOrClone to be executed first so that when wd.AutoGeneratedFilePatterns(vcsDir) is called, it can find the .gitattributes file. wd.PullOrClone will populate the directory so without it, the first run of this flow will not see accurate results for autogenerated files

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh gotcha, that makes sense.

vcs/git.go Outdated
if len(matches) == 2 {
pattern := strings.ReplaceAll(matches[1], "**", "*")
pattern = strings.ReplaceAll(pattern, "*", ".*")
filePatterns = append(filePatterns, pattern)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Could you add a test for this pattern-to-regex conversion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah i might change this logic (see my comment about regexes and using direct file paths instead). but either way, i will add a test for the code added in this file!

@@ -693,7 +693,7 @@ var ContentFor = function(line, regexp) {

var FileContentView = React.createClass({
getInitialState: function() {
return { open: true };
return { open: !this.props.isAutoGenerated };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be nice to put an [AUTOGENERATED] badge next to the file path. That's not a blocker of course, but it would be a nice visual indication about why the file is collapsed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea, will do!

@salemhilal
Copy link
Contributor

Ok! Two asks before I approve this:

  1. I think the glob-to-regex logic is fussy enough that we'd want a test for it.
  2. Can you add this feature to our README?

One other thought on the feature itself: it might be worth having an override for this feature in the config. For example, you might have a .gitattributes file, but you want a different set of files to be marked as autogenerated. Or, you might not be using git at all. In those cases, you could specify a list of autogenerated files in your repo config which would take precedence.

@ivantsepp
Copy link
Contributor Author

Thanks for taking a look and glad you think this feature is worthy of being added! I agree we can follow Github's approach where we hide but still index/search on these autogenerated files.

I'll look into adding a badge, adding documentation into the README, and adding config override!

Actually for the glob-to-regex logic, I'm not sure it's the right approach anymore. I just realized that you could nest .gitattributes in your directories so parsing out only one file that's in the root isn't full coverage. What about running a shell command like git ls-files | xargs git check-attr linguist-generated. Then we would get specific path names and we wouldn't need to regex anymore (we could just do a simple string comparison). Thoughts on this approach? I like this too since we can use AutoGeneratedFiles instead of AutoGeneratedFilePatterns (shorter name).

(sorry for not responding earlier!)

@salemhilal
Copy link
Contributor

@ivantsepp your response rate is still probably better than ours on this repo! That approach sounds more than fine to me. It looks like git check-attr accepts a -z flag to make its output be machine-readable, but in honesty I couldn't get it working as expected locally. I'm definitely in favor of that shell command approach regardless — the world is a better place with fewer regexes 😅

@ivantsepp
Copy link
Contributor Author

Flushed out that approach and added a badge!

Hound

Added config override and added docs for that. Though I wasn't sure if I should add notes in the main README about this?

}
}

if err := filesCmd.Wait(); err != nil {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Followed the pattern in the example in https://pkg.go.dev/os/exec#Cmd.StdoutPipe so hopefully this is right

@ivantsepp
Copy link
Contributor Author

ivantsepp commented Aug 23, 2022

friendly bump! was hounding the other day and was reminded that this feature would be cool! Any thoughts on the revised PR?

@salemhilal
Copy link
Contributor

@ivantsepp Thank you for the bump! I think these updates look good. I'll float this PR around with the rest of the folks to see if there are any objections, but otherwise I'll merge this and cut a release. Thank you again!

@salemhilal salemhilal merged commit d2f8655 into hound-search:main Aug 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants