Hacker News Reader

Comment by nikanj | Hacker News Reader

Social network features are such a 2015 me-too fad feature anyway. What they should add is AI, or maybe blockchain.

Before adding the newest fad features, maybe the should go back and add old fads that they missed.

One big fad from 50+ years ago that I'd welcome is folders. I don't want to just have all my repositories appear in a flat list ordered by time since last update. I want to make folders so I can organize repositories by topic--just like I have my repositories organized in my computer.

The modern version is tags, but they lack good sorting/viewing for tags

Not wanting to start a discussion about graphs vs trees for organizing, but in my opinion simple folders are great to fulfill basic needs. I cannot imagine a book having no table of contents and just a list of tags with numbers indicating relevant page numbers.

That is just dumbing yourself down in favor of machine classification or search algorithms while a simple solution exists for this problem for higher order classification and context, which tags alone fail to provide, even with sorting.

Depends on a book type I suppose. Most have "index" section, which is just a list of tags. In recipe books I find it more useful than ToC actually.

Al entry should go in a single category, chapter or folder. The index should provide a useful overview. Tags you may have in any amount. More is usually better.

A tag with a single entry is useful. Chapters should never have a single entry.

I think it depends on your goal. If I want to browse new chicken recipes, I am going to open the table of contents, find the section on poultry and start flipping through recipes. On the other hand, if I want to cook a chicken curry, I am going to go to the index and look up curry, then find the relevant page.

Folders are great for when you don't know what you want and just want to browse or explore based on broad topics. Tags/indexes are better when you know basically what you want, and you just need a way to find it or items similar to it.

With limited entries of text or code you can just have them all on one page. Slightly more requires a folder or category system. If you have even more you need tags you should also keep the categories (everything must sit in a single category), If you have even more you need categories, tags and search. Trying to use one of those for the wrong volume just creates clutter.

It’s surprising to me that they don’t just do a folder based view using tags and relationships among tags.

I don’t like being restricted to single folders, but I’d love to symlink projects into multiple folders.

This would work out well if they just added some graph functionality among tags.

JFYI, they have those in gitlab.

Here's an example.

https://gitlab.com/gitlab-org

Ye, bit its not GitHub ;)

Exactly ;)

not everyone gets a choice in tools...

but many do.

My favourite fad of the last few decades is: sorting.

You know because in Github you can't even sort your list of repositories.

HTML cant even sort

JS can though, so can Ruby.

It doesn't belong there in my view.

We started out not knowing what anything should look like, we didn't even know what computers were suppose to do. Everything had to be envisioned and implemented. Different approaches were taken for a lot of things. Eventually we just know how something should work. At that point it can be abstracted away.

Similarly lots of things should stay in JS. If we've experimented and evolved to the point where we know how something should work we should grow beyond modules and have build in methods for it.

It is happening but much to slow in my opinion.

Say, we have a Date API, are week numbers a thing or not? Are they an unpredictable poorly understood thing? Does it bother anyone if the API supports it?

Everything should be able to migrate up and down from the metal to the highest level of abstraction depending on how much we use it.

edit: There is no point shipping [table] sort magic to the client on every page view that needs it.

It seems like you're simultaneously saying "sorting doesn't belong as a language function in JavaScript" and "we shouldn't ship a sorting routine to the client," which seems...odd. If the page view needs sorting, then isn't that the use case where we can most say that there is, in fact, a point to "shipping sort magic to the client"?

(Also, you can do an HTML table sort in about 10 pretty short lines of code[1], so this seems like a kind of weird hill to die on.)

[1]: https://stackoverflow.com/questions/14267781/sorting-html-ta...

JS should have an array sort function. HTML should have sort-able tables. We know what they look like. We shouldn't have to pump up our pages with a bazillion lines of js just to implement something entirely obvious.

IOW: If there is a table it doesn't hurt to be able to sort it by default.

The example is great! 10 lines... no wait... 30 lines... then you have something that... or no wait, it sorts numbers alphabetically. The cursor is wrong. There is no accessibility. The little arrows are missing ▲ ▼ did I pick the right ones? They look bulky, better add another span inside the th? Oh I clicked the th twice now the text is highlighted.

Why should I need to implement this myself? I'm not inventing anything new? I don't want to be dealing with colspan but we all know how it should work? I know its wrong but I usually leave out the <thead>, tables render just fine without it but when something generates tables like that the script needs to be re-examined to figure out why it doesn't work. There is some unknown number of other ways to break it.

A default implementation could deal with some common units out of the box. Monday could go in front of Tuesday, 50 cm could be smaller than 1 m, $100 could be bigger than $20. Just the simple obvious stuff. For everything else something like <th sort="foo"> with: foo = (a,b) => a.length - b.length

List items are a bit less obvious but I'm sure we can think of something sensible. Perhaps sorting by child class?

What is the drawback?

It sort of can with the Flexbox order property.

Neither can jpg.

This so much. Another pet peeve of mine: GitHub is terrible for the workflow that Git was originally designed for. Specifically, the issue that there's no good way to review patch series. The key here is presenting a series of patches as a whole, but allowing reviews on individual commits of the series.

Assuming that we're talking about the same thing, this is possible in GH from the `Files` tab on the PR screen.

Not really. You cannot comment on the commit message itself. And, if I'm not mistaken, changes made in one commit that are undone in a subsequent commit won't show up even if the files view if filtered by commit.

Also, it's difficult to tell which comment is associated with which commit.

I don't think I ever factor in commit messages into my code reviews. I may look at the commit history if I want to see how they experimented implementing the feature, but I only care about the end goal and the code I will be merging in at the end.

The issue is that Github actually discourages reviewing by commit because it makes it difficult to do so. Though there are those who are only interested in the overall diff, there are others who want to be able to maintain a clean and informative history via version control. When the review system makes it difficult to ensure that's the case, then then version control history cannot be maintained.

Precisely. We're in a vicious cycle where most people using Git don't use what ought to be Git best practices for most serious large scale projects (clean history with self-contained logical commits and good commit descriptions) because GitHub makes it so difficult to do this. And to be fair, GitLab really isn't much better in this department.

And there isn't enough pressure on GitHub or GitLab to clean up their act because most people don't even know what they're missing. And so the cycle continues.

If you use squash and merge this won't be a problem, you will have a "clean history with self-contained logical commits and good commit history", and intermediary commits won't matter anyway.

Some features take more than a single logical commit to implement. Looking at the git mailing list, I see patch series containing anywhere from 1 to 10 commits (with some as many as 15 commits).

Also, having a single commit touching many parts of the code makes it harder to revert due to a greater chanche of conflicts with other commits.

This is my second or third biggest problem with GitHub. If I want to submit a patch—the thing that Git was made for—I cannot use GitHub to do it. Assuming one has already gone through the "create a GitHub account" step, my closest option is to go to github.com to create a completely unnecessary on-GitHub "fork", go back to my local copy to add that remote and push to it, and then go back to the github.com and click around to submit a pull request.

Pull requests in Git were designed for trusted, frequent collaborators. I.e., project maintainers that are routinely syncing with one another. It's not supposed to be the preferred mechanism for ordinary contributions, and certainly not for drive-by contributions.

My biggest gripe, though, is that the on-GitHub fork from the first paragraph will live on in my namespace forever, unless I manually prune it. And even if I do prune it, I still have no way to control the fact that GitHub has silently set up a social networking timeline to broadcast a centralized index of all this activity to anyone and everyone, without asking me, and without a way to manage the stuff that goes into the timeline, control who it's shared with, or turn it off completely.

So, something like https://docs.gitlab.com/ee/user/group/ ? But this is gitlab.

I’ve recently switched from GitLab to Github enterprise due to a job switch. I am shocked at how bad Github enterprise is to navigate. It seems like I regularly have to depend on the search function to find the repo I want.

I agree completely. I miss folders for YouTube subscriptions as well. It seems folders are on the way out in most modern tools and apps.

Yay! There's one thing I would absolutely love about having a blockchain in GitHub: The transfer fees.

If everyone had to pay $1 to submit an issue and/or a pull request, open source projects would get a lot less "support spam" :)

Also, it would certainly help if people need to wait 10 minutes for their last comment to be accepted into the network before they're allowed to comment again.

> If everyone had to pay $1 to submit an issue and/or a pull request, open source projects would get a lot less "support spam" :)

I dunno, that seems odd. Do you not want to know about bugs in your project to make it better? I realize people will submit a bug b/c they can't figure out how to implement something but that is worth being aware of real bugs in the code.

Now if you could "tax" the "+1" spam culture, I'd be all aboard that

Do people still do that? How long has it been since they added reactions?

Not only do I still see it but I ALSO see the thumbs up comment instead of just clicking the thumbs up reaction

/cries

I would like end-to-end encrypted repositories even they can't read - like keybase!

Thats possible now, right. If they supported it more I’m not sure how much value over just encrypting blobs. I wouldn’t trust github’s clients or servers to do it for me.

Keybase's remote helper (which does the crypto) is open-source, so if github did something similar you wouldn't need to trust them. That's the value of e2ee -- you don't need to trust the intermediaries, whether they start misbehaving, are forced to hand over data, get hacked, etc.

>maybe blockchain.

but git is already a blockchain. each commit is a "block", with a reference back to the previous commit.

There was this one guy, whom was a cryptocurrency fanatic but not a developer, who tried to convince me to get involved in a "blockchain code database for developers". I told him that Git uses a blockchain, and he simply couldn't accept that a blockchain has been used for years on something that isn't cool or possible to monetize.

It's pretty funny how people still think that a blockchain is this magical thing, yet I'm pretty sure anyone on HN is capable of writing a blockchain in an an hour or two. Maybe even less than that.

I have a funny story about how I told a colleague who was really into blockchain how I had updated our project to use a blockchain.

I demo’d github and described the distributed features with pull requests and stuff “oracle-based mediation.”

It was funny because this was maybe 3 years ago and had never heard about GitHub but had read all the blockchain literature.

That reminds me how people wanted Wikipedia move to blockchain:

https://twitter.com/jimmy_wales/status/1226868636020805632

https://news.ycombinator.com/item?id=22296659

They should add cross referencing (click on a symbol and jump to the definition, even if it is in a different repo).

This is actually coming online already. I don't remember what languages support it, but it's not very many.

This blog post seems to indicate Python, Ruby, and Go: https://github.blog/changelog/2019-11-13-code-navigation-is-...

I'm sure that will increase over time.

> What they should add is AI, or maybe blockchain.

So they should add 2018 me-too fad features?

Don't forget to write monoliths, have monorepos, only use PostgreSQL for all database needs, and use Kubernetes even when you don't need it.

And a monorail!

And my axe.

Also, did they rewrite in Rust already?

Reply on news.ycombinator.com