Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives.

If you think you can do it better then go ahead and try build the product and then pitch it.



Usually problems arise before solutions. I’ve been thinking the same things and welcome this post.


Except the author did not really give problems. They gave a list of features they think would be needed, and some of those implied problems... but this post was a list of desired solutions. I have no idea what specifically they meant when they referred to git having pain points. I can guess based on my own experience, but a list of specific problems would have been lovely.


I didn't recognize the author, but came here to say the same thing: where are the ideas on how these improvements would be implemented?

Without making an attempt at implementation, you (the generic you, not the person I'm replying to) have no idea what the real issues are. Even failed or partial implementations are more instructive than armchair criticisms, or thought experiments where you can just handwave away all the competing constraints that need to be considered, whether in Git or in any erstwhile successor.


Fair, although I think we need to understand git’s shortcomings to understand what product needs to be built next. I’d argue that’s what this author is doing.


Of course concrete ideas are better. But even armchair criticisms can be important (or at least interesting), to open up the discussion.

While git is good and powerful in many ways, git frankly has many deficiencies, yet everybody treats it as the holy grail of version control. Just because Linux uses it, GitHub exists or something else, I don’t know. The author lists many valid points that are not all sci-fi and that would multiply the usefulness of the vcs sevenfold.

Someone has to point out the elephant in the room.

It could spark the idea for someone to invest in something new and better or for someone to contribute improvements into git.


The skills necessary to solve a problem, are also the skills necessary to realize there is one in the first place.


I’ve got one, poverty I realise the problem no idea and I bet no one here has an idea how to fix it without breaking a lot of other things

The list goes on


I feel your pain.

And your pain is distributed systems. Not just of source control, but bug tracking. And general process-manager-y stuff.


What’s wrong with the author?


Well, you can look at the author's past HN submissions to see what was meant.

It's basically click-bait for hackers. "How to do X technology better" with a few paragraphs of ideas, and taking no responsibility for actually doing something about it, aside from hoping that their vision might inspire someone else to put in the hard work.


Some of us like to read ideas. The blog is more on the personal brand building side, sure. But I'm mainly coming to HN and comments to read what other people think about stuff.


Why do they have to take responsibility? I can point to so many oss projects where someone else’s vision was implemented.


Confuse "is" vs "ought" much?

I didn't say they have to do anything. I did observe a pattern.

There is a difference between saying everyone should take responsibility for fixing all their criticisms and noticing that a particular person never takes responsibility for any of their criticisms.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: