Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is too hard

changelog.com

Post reply on HN
Print view View original

741–750 of 821 posts

Re: Git is too hard

#741

Post by horsawlarway »

wpietri wrote: post #644
weehoo wrote: post #488

Earlier quoted context omitted.

You can’t unsend an email because you can’t force someone else to delete something. Emails end up as files on someone else’s server. Claiming this is a UX issue is intentionally missing the point. If this is legitimately a foreign concept to you, an afternoon setting up postfix and playing around with it might be worth your time. Email is a protocol, not a program. A “delete” request would be just that, a request. Yo…

Thanks for the explanation, but I ran mail servers for ~25 years. I am familiar with the technology, and in the mid-90s even wrote a chapter of a book explaining email. And I've been using version control even longer. Maybe try rereading what I wrote without the assumption that it comes from ignorance.

I think your comments are coming from ignorance, though.

Without trying to be snarky - All your comments directly ignore that what you're proposing values one stakeholder more highly than another.

People keep pointing out that there are two users involved in this exchange, and they both weigh equally, and you dismiss them and talk about running mail servers 25 years ago (who cares?).

You keep saying "I should be able to unsend my email". Let me rephrase your question - Why should you be allowed to delete my email?

Re: Git is too hard

#742

Post by hinkley »

thrwyoilarticle wrote: post #213
rakoo wrote: post #167

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…

+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…

> If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire.

Whether you realize it or not, that's gatekeeping. The point of UX is to remove artificial gates. When people apologize for the gates instead of fixing them, well... That's tantamount to threatening people's livelihood. It's a lot easier to do that when you don't think of it that way, and it probably shouldn't be easy. "I understand it, you shouldn't work here if you don't" is literally, "Fuck you, I got mine," with different words.

> about git being hard. But there is a shortage of effective, popular competitors

There is only so much oxygen in a room. There is not space for a million solutions to every problem, and once the Hype Train has left the station all you have left is to make the fiction true, or try to accelerate the Trough of Disillusionment so we can get on with fixing the problems instead of deflecting.

And I say this as the only person on a large team fit to do anything approaching surgery on screwed up git repositories. There is frequently a degree of turf protection via "he's a bastard, but he's our bastard". No, he's just a bastard. I don't claim any responsibility, I just have to interact with him.

Re: Git is too hard

#744

Post by horsawlarway »

Spivak wrote: post #607
horsawlarway wrote: post #460

Earlier quoted context omitted.

I think you're twisting the problem statement a little here. Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back". The problem is that, regardless of your intent, you've given something to someone and they own it now. You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email). And I want to be clear upfront…

I think you're missing the forest for the trees here. The point of version control systems is to make developing software easier. It's a tool that exists for the convenience of its users. It's reasonable for people developing software to ask for the ability undo a change or restore a repository to the way it was a second ago. Telling a team of people using Git "it doesn't work like that" is unhelpful because it's not…

> But there's nothing holy or fundamental about an implementation detail of how Git does things that makes their use-case hard.

Yes, yes there is.

I've worked in systems like you're describing (CVS, SVN) - The problem is that they ALL require locking.

Locking freaking sucks. It sucks SO INCREDIBLY MUCH more than dealing with the complexity of a real distributed system that git won, even though its cli interface is a god-damned nightmare.

You clearly haven't had a co-worker lock a file you need to edit and then go on vacation.

Re: Git is too hard

#745

Post by petepete »

edflsafoiewq wrote: post #259
rjmunro wrote: post #212

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

checkout -b seems more logical to me, but not even close to 1000x more logical. Whether it should go on branch or checkout is just an opinion. You're blowing some tiny disagreement up to ridiculous levels.

These days you can use `switch -c` instead. Switch makes so much more sense to me.

https://git-scm.com/docs/git-switch

Re: Git is too hard

#746

Post by TheKarateKid »

rossdavidh wrote: post #410

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long d…

> If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long drawn out cycle of embarrassment. No matter what happens, it was not git's fault, it was your fault.

Ready to be downvoted into oblivion for this, but: This is how a lot of the Linux/FOSS community is so it makes sense that Git is too, sadly.

Things have gotten a lot better with the attitude these days, but you know it's bad when StackOverflow needs to issue guidelines on being polite and how to answer questions without being rude/condescending.

Re: Git is too hard

#747

Post by hinkley »

rakoo wrote: post #167

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…

I think we're all still dancing around a blind spot, where we want eventual, Pareto Principle consistency (where a consensus is formed around 10% of edit histories, many others require only a consensus of 2, and the rest are backups that require a consensus of 1)

We're trying to assemble this from different pieces, without a clear idea if we can even get there from here, given all of the roadblocks Information and other Theories throw in the way.

I hope someday we meet in the middle with systems that can handle code and incidentally a bunch of other problem domains we also care about.

Re: Git is too hard

#748

Post by flippinburgers »

simiones wrote: post #438
ritchiea wrote: post #432

Earlier quoted context omitted.

I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.

How can you pull without using stash? Do you always commit everything before pulling? You also need the log daily to know things like "what changes made it into this build", or almost everytime I fix a merge conflict, to understand why something is the way it is. I can grant that cherry-pick & blame are more rarely used, though blame is often on by default in many editors, and cherry-pick is something my team does da…

I feel like the response is why wouldn't you use a separate branch for your feature/changes?

Re: Git is too hard

#749

Post by hinkley »

zeroimpl wrote: post #738
marcus_holmes wrote: post #583

Earlier quoted context omitted.

I found the author's apparent belief that Git and Github are the same thing extremely annoying. Github is a parasite.

Not just that, they seem to suggest Github created Git... > the quality of the tech that is Git is a testament to GitHub being able to make it this far in the tech space But in reality, Github makes Git more complex, because now you have to understand the concept of forks. Not only is there your local copy and an origin, there is a 3rd repository in play.

What other structures would work for having a public forum for PRs?

I'm having trouble coming up with many that would be compelling enough to make that change, especially once you consider bad-faith actors in there (eg, I can't flood your git repo with my nonsense, because my code doesn't exist in your repository until the PR is merged)

I spend too much time doing archaeology to support squashed PRs, which eliminates a few alternatives I might otherwise suggest.

Post reply on HN