Hacker News Reader

Comment by sqs | Hacker News Reader

Sourcegraph founder here. We built this to make it much easier to grok code. It saves us hours every day. Would love to hear your feedback!

The README has some good links to try Sourcegraph at https://github.com/sourcegraph/sourcegraph/blob/master/READM...:

https://sourcegraph.com/github.com/square/okhttp/-/def/JavaA... (semantic code browsing for Java)

https://sourcegraph.com/github.com/golang/go/-/info/GoPackag... (http.NewRequest used in 8801 repositories)

Sourcegraph supports Go and Java right now. If you want to get access to the upcoming beta of JavaScript, Python, or other languages, send us a note at support@sourcegraph.com or https://twitter.com/srcgraph.

View on HN

> These URLs always refer to the latest definition and won’t break if the file is edited, unlike links to a specific line number.

You can always get the URL on GitHub for a particular line number at a particular revision which won't break when the file changes. A persistent link to a function can break in a different way in that maybe the function, while named the same, changes behaviour in a way that it no longer does exactly what it originally did. It's not obvious to me which of these breakages is more relevant.

When you talk about "hackable" URLs it would be great to be able to get a URL for a named function at a particular revision. This solves both problems. I have an immutable reference to a particular piece of code, but then by hacking the URL I should be able to still see the most recent version.

Exactly! You mean like this? https://sourcegraph.com/github.com/gorilla/mux@9fa818a44c2bf...

Exactly :) Cool! Although it seems weird to me to have the revision in the middle of the URL.

This also works for tags and branches (or any 'ref' for that matter instead of the sha1)

Where would you want the revision? At the very end? Right now, it's associated with the repo, which makes sense and is easier on our URL routing. But I'm curious to hear what you'd prefer.

Actually on further thought maybe this does make more sense. I don't really have a strong preference either way anyway.

I think I agree with parent - if the premise is that the units we're dealing with are the functions, then I want to usually access `/function`, and `/function/revision` is being more specific.

I get what you're saying, but it seems like the URL mixes where you're coming from with where you want to take us.

I think it actually makes sense there, as a logical hierarchy: you want a given repository, at a given revision (e.g. a commit hash), and a given file within that revision.

I notice that the URLs contain file paths in them. What happens if you move a function to a different file? A different sub-directory in the project? Would the url continue to work?

(Hi Quinn! We met last year after the discussion around https://news.ycombinator.com/item?id=8308881)

Hey Kartik! Good to hear from you. They contain package paths, such as Go import paths or Java "com.example.mypkg" paths, but not file paths.

At least in the case of Java package paths map 1-1 with file paths, right? Is Go similar? In that case, moving a function to a different package/directory would change the url? Would the old url break, or continue to show the old/stale version?

Yep, but those languages also define equality in their type systems using the package paths. It's tricky, of course. :)

We want to be able to track function moves and renames across packages or even repositories. It'll take some more work to get there.

Yes, certainly a hard problem. I'm just trying to understand what happens today. Does the link break or (better) just stop getting updated?

It will break if there is no revision, or a non-absolute commit ID (such as a branch or tag). An absolute commit ID link will continue to work.

Reply on news.ycombinator.com