5 ms·

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

• michaelmior 10y ago
  > 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.
  • beliu 10y ago
    Exactly! You mean like this? https://sourcegraph.com/github.com/gorilla/mux@9fa818a44c2bf1396a17f9d5a3c0f6dd39d2ff8e/-/def/GoPackage/github.com/gorilla/mux/-/CurrentRoute https://sourcegraph.com/github.com/gorilla/mux@9fa818a44c2bf...
    • michaelmior 10y ago
      Exactly :) Cool! Although it seems weird to me to have the revision in the middle of the URL.
      • the_common_man 10y ago
        This also works for tags and branches (or any 'ref' for that matter instead of the sha1)
      • sqs 10y ago
        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.
        • michaelmior 10y ago
          Actually on further thought maybe this does make more sense. I don't really have a strong preference either way anyway.
        • OJFord 10y ago
          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.
      • JoshTriplett 10y ago
        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.
• akkartik 10y ago
  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 https://news.ycombinator.com/item?id=8308881)
  • sqs 10y ago
    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.
    • akkartik 10y ago
      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?
      • sqs 10y ago
        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.
        • akkartik 10y ago
          Yes, certainly a hard problem. I'm just trying to understand what happens today. Does the link break or (better) just stop getting updated?
          • sqs 10y ago
            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.
• deleted 10y ago
  [deleted]