Hacker News Reader

Comment by plorkyeran | Hacker News Reader

Do I understand correctly that GitHub currently doesn't support SHA-256 repos at all, so the author faked a screenshot of what the create repository UI would look like if they choose a really stupid way to add support for SHA-256 repos, and then proclaimed it an unsolveable problem? Selecting the repository format based on the first thing pushed to it is really not a crazy idea.

The submodule problem is real, but the forge problem is entirely just "if forges implement support in a way that makes it painful it will be painful", and that's true of literally every feature that requires forge support.

View on HN

I did generate that screenshot as I am not in the beta for this - I don't think many outside of GitHub are. However, this is exactly how GitLab does it and I would be _really_ surprised if this is not almost exactly how it's implemented. There is almost no other reasonable way to do it.

You can't select the repository format based on the first thing pushed to it, because both sides have to be initiated before a transfer can happen.

So you either start the project on the server and then clone an almost empty repository to start working (which I think is rare) - in which case you need to choose the format like this.

Or you initialize it locally and start your project and then push it to GitHub at some point, in which case you need to initialize a server side version that matches the format to push it to. There is no "initialize a new thing on push" and there never has been.

I personally would have preferred if there is a proper disclaimer that the screenshot is an approximation of how the UI would be. Or alternatively, use a more distinct art style of conveying the UI (e.g. comical/sketch lines or whatnot).

Right now its only a vague statement of "will need to look something like this", which does not imply on the originality of the image. I myself am misled that the screenshot is a legit UI.

The caption literally says "will need to look something like this"

> There is no "initialize a new thing on push" and there never has been

Well, there hasn't ever been a real reason for it, and now there is?

> both sides have to be initiated before a transfer can happen

What would be preventing a forge from answering with a reference to schroedingers octocat when inquired about the yet-undefined properties of a newly created repository? The first pushing client explicitly looks for it, and no final decision has be made server-side until someone wants to take a peek, no?

I also don’t know how big this problem really is. You practically have two ways of creating a repo. Local first and push or create a repo remote with Readme etc and clone.

The submodule issue is a different beast. But that one is currently a problem as well when a person choose a http url or ssh url. I have some extra git configs to normalize everything to ssh for instance.

github does support sha-256 repos in some kind of private beta. https://github.com/bk2204/talk-rust-in-git is one of them.

but yes: that ui in the article is likely entirely imaginary, but it's likely an option (either in the ui for private beta users or by raising a support ticket or by some internal tool) to get sha256 repos today.

I completely agree with everything you say here. I felt the critique in the article was way more strawman falacy than everything else. I use(d) git much more locally, and would never run into this problem because I would only use sha-256 on new repos. Rewriting the entire history is also not so much of a pain depending on organisation size and how it is done (if an org decided to do it). It may be a pain for git-hosts, but even there i think reasonable solutions can be found. Still not sure if I care about the switch though sha-1 worked and the security implications seem minor to my use-cases. I am much more concerned with code leaking online...

sidenote: i hate the term "forge", is it too late to settle for something less... cringe??

Reply on news.ycombinator.com