Hacker News Reader

Comment by simoncion | Hacker News Reader

> One concern would be around tools that fetch from github automatically.

Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right?

> ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings]

I mean, the JavaScript development community has -collectively- decided on a huge bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?

View on HN

Go get does not start with a git clone. If you go get example.org/pkg/foo go fetches https://example.org/pkg/foo?go-get=1. So coordination between go and github could implement something for deprecated repositories without changing anything in git.

More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths

> Go get does not start with a git clone.

Fair enough. (I don't use go, so I'm unaware of pretty much all of its internals.) [0]

> ...coordination between go and github could implement something for deprecated repositories without changing anything in git.

A couple of things:

* This only fixes things for Golang. It doesn't fix it for the couple-thousand other tools that pull things from Github.

* I never suggested changing things in git. That would be freaking nuts. :) EDIT: Or did you mean "without changing anything in the git repo"? If you meant that, then I strike this bullet point and apologise for the noise. :)

* Frankly, having a well-known file in your Git repo that contains meaningful tags seems far more compatible than changing git, or altering the $BUILD_TOOL<->GitHub integration... for one thing, the convention could be trivially adopted by non-git users. :)

[0] Thanks for the documentation link, BTW! :D

I am not your grand parent poster but I fully agree with you and I'd go further than that.

The people who ask for more proprietary features (or should I say anti-features) in Github are encouraging lock-in inside of Github. Github ought to be a hub. I'd like to emphasize on the hub part as it should be one hub out of many. It should not be the center of the software universe any more than AT&T/IBM/Microsoft/Google/Facebook/Uber.

> Github ought to be a hub.

So, I heartily agree that vendor lock-in is bad. [0] However, git doesn't handle mailing lists, or issue trackers, or hands-off repo push access control, or.... So, if you're going to do more than just serving git repos, you're almost certainly going to have to do these things yourself, and you very well might end up doing them in a way that differs from how everyone else is doing them.

I mean, as long as you can get complete exports of the data in the important non-git bits, who cares, right?

[0] I'm STILL mad about how Hangouts turned out.

At the very least, we could try to create standard conventions for vendors like github to adopt

Reply on news.ycombinator.com