[e-dard]

Maybe that's just poor documentation on the author's part. If you simply try and go get the package (running Go 1.5 here):

    ~ $ go get -u github.com/otoolep/syslog-gollector
  warning: code.google.com is shutting down; import path code.google.com/p/log4go will stop working
  warning: code.google.com is shutting down; import path code.google.com/p/snappy-go/snappy will stop working
    ~ $

Everything is fine (aside from the warnings about code.google shutting down).

Yes, Go does not have a culture of versioning, but it _does_ have a culture of _vendoring_. You should be getting your reproducible builds by vendoring your dependencies. That way, you don't need to do any hunting or git-bisect shenanigans.

[kasey_junk]

Except in your example your command will update the vendored code, potentially (and in some cases probably) breaking dependencies.

It is a fact, that the go dependency management story is weaker than nearly any of the other modern development environments there are. It is getting better through time, and probably won't a problem long term (and for many people isn't a problem now). But lets not act like it isn't a weakness.

[ldite]

> You should be getting your reproducible builds by vendoring your dependencies.

As I said, I've been working with code I didn't write: I've effectively been taking other people's *hub code and vendoring it for them, because they haven't. This is not optimal.

And this isn't trivial projects, either, e.g. https://github.com/influxdb/influxdb/ (also connected to the author!) still uses trivial go get, and doesn't make any effort to help with vendoring.