5 ms·

Thank you! Any complaints/requests/other feedback? How could we make it better?

by sqs 7y ago

escardin 7y ago
Yes! Publish a graphql schema that is parseable by apollo graphql please! I tried to use your API on my companies internal source graph setup and had to hand roll my API calls because of these errors.
- loicguychard 7y ago
  Sorry to hear you this didn't work for you! I filed an issue on sourcegraph/sourcegraph, would you mind posting more details there about the errors you ran into? https://github.com/sourcegraph/sourcegraph/issues/8970 https://github.com/sourcegraph/sourcegraph/issues/8970
voz_ 7y ago
I'm at FB now and we have an internal code search. I apologize, I can't recall any feedback for sourcegraph.
HiJon89 7y ago
Seems like this is in the works already, but the boolean operators in OpenGrok are so intuitive and powerful. I use them every single day and the lack of support in Sourcegraph immediately disqualified it for us. For example yesterday I was looking for Dropwizard Managed classes not annotated with @Singleton so I did: Managed && !"@Singleton" (I'm omitting the fully-qualified class name for brevity) If I also wanted to look for HealthCheck classes I could update the query to: (Managed || HealthCheck) && !"@Singleton" I think it also helps that OpenGrok has a separate input for filtering file paths (completely splitting the "where" and the "what" parts of the query). And this file path search supports the same boolean operators. So if I want to narrow my search to two particular repositories I could put CrmSearch || AutomationPlatform into the File Path input. And because this input only handles file paths, I don't need to remember any special syntax. Whereas if you clump the entire query into a single input, then users need a way to tell you whether a search term applies to file paths or file contents.
- rvttt 7y ago
  Engineer at Sourcegraph here. Adding boolean operators is a priority on our roadmap, and expected to go live between May and July this year. On separate inputs: definitely something we've also identified and are actively working on. One recent experimental addition is "Interactive mode" that lets you enter patterns separately for repos, files, and patterns, and so on. There's a dropdown next to the query bar to try it out--there are some kinks, and we're currently working on making this a polished feature. Thanks for the feedback, and stay tuned!
  - HiJon89 7y ago
    Awesome, thanks for the response. Looking forward to trying out Sourcegraph again

Thank you! Any complaints/requests/other feedback? How could we make it better?

by sqs 7y ago

Thank you! Any complaints/requests/other feedback? How could we make it better?

Yes! Publish a graphql schema that is parseable by apollo graphql please! I tried to use your API on my companies internal source graph setup and had to hand roll my API calls because of these errors.

loicguychard 7y ago
Sorry to hear you this didn't work for you! I filed an issue on sourcegraph/sourcegraph, would you mind posting more details there about the errors you ran into? https://github.com/sourcegraph/sourcegraph/issues/8970 https://github.com/sourcegraph/sourcegraph/issues/8970

voz_ 7y ago

I'm at FB now and we have an internal code search. I apologize, I can't recall any feedback for sourcegraph.

HiJon89 7y ago

Seems like this is in the works already, but the boolean operators in OpenGrok are so intuitive and powerful. I use them every single day and the lack of support in Sourcegraph immediately disqualified it for us. For example yesterday I was looking for Dropwizard Managed classes not annotated with @Singleton so I did: Managed && !"@Singleton" (I'm omitting the fully-qualified class name for brevity) If I also wanted to look for HealthCheck classes I could update the query to: (Managed || HealthCheck) && !"@Singleton" I think it also helps that OpenGrok has a separate input for filtering file paths (completely splitting the "where" and the "what" parts of the query). And this file path search supports the same boolean operators. So if I want to narrow my search to two particular repositories I could put CrmSearch || AutomationPlatform into the File Path input. And because this input only handles file paths, I don't need to remember any special syntax. Whereas if you clump the entire query into a single input, then users need a way to tell you whether a search term applies to file paths or file contents.

rvttt 7y ago
Engineer at Sourcegraph here. Adding boolean operators is a priority on our roadmap, and expected to go live between May and July this year. On separate inputs: definitely something we've also identified and are actively working on. One recent experimental addition is "Interactive mode" that lets you enter patterns separately for repos, files, and patterns, and so on. There's a dropdown next to the query bar to try it out--there are some kinks, and we're currently working on making this a polished feature. Thanks for the feedback, and stay tuned!
- HiJon89 7y ago
  Awesome, thanks for the response. Looking forward to trying out Sourcegraph again