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

Git undo: We can do better

blog.waleedkhan.name

Post reply on HN
Print view View original

371–380 of 490 posts

Re: Git undo: We can do better

#371

Post by seoaeu »

symlinkk wrote: post #308
seoaeu wrote: post #180

Earlier quoted context omitted.

The thing with command line interfaces is that since the same interface is used by humans and computer scripts, you essentially end up with an unversioned API that you can never make breaking changes to.

It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.

With other sorts of APIs you are given the choice between say the v1 version or the v2 version, with both endpoints being available at the same time. However, when it comes to command line programs for all practical purposes you can only have a single version installed at a time. And it of course doesn't help that essentially none of the existing scripts even check the versions of the software they run.

Re: Git undo: We can do better

#373

Post by geitir »

jonathanberger wrote: post #219

Git is one of those bizarre products that has remained a leader in its category for almost a decade while being extremely difficult to use, even for experts. Another one of these products is Apache. Why is this? At least from my naive point of view I would expect these extremely user-hostile products to have been overtaken but more user-friendly alternatives. I know the best products don't always win, but when they d…

Some people secretly like making things needlessly complex

Re: Git undo: We can do better

#374

Post by jollybean »

jonathanberger wrote: post #219

Git is one of those bizarre products that has remained a leader in its category for almost a decade while being extremely difficult to use, even for experts. Another one of these products is Apache. Why is this? At least from my naive point of view I would expect these extremely user-hostile products to have been overtaken but more user-friendly alternatives. I know the best products don't always win, but when they d…

This is a really, really good question. Some things:

- It's fast, which we all love. - It mostly does painless merges, again we love. - It's not actually that hard to 'get going' - and I think that a lot of people are totally overconfident in their skills. - It's free - It's open source - Linus Torvalds created the critical mass for Linux - GitHub - Lack of truly efficient alternatives - It technically 'works' i.e. does what it's supposed to do, relatively robustly. - It's designed for open source, which is a novel concept.

Personally, I'm scared of git from an organizational perspective, and I do not feel that we have reconciled the reality of how much pain it can cause to people, newer teams, the less familiar etc..

If people would pay for software I wonder if a great alternative could come to the fore because without it, we have to rely on volunteers and that's an ugly industry problem.

Re: Git undo: We can do better

#375

Post by unknown_error »

still_grokking wrote: post #354
unknown_error wrote: post #325

Earlier quoted context omitted.

The point is that you shouldn't have to learn everything by brutal trial and error, losing hours of work each time you try to learn a new operation and make a small mistake. It's the same reason consumer operating systems have a trash can and undo features. Just railing on people with "you should've known better" doesn't really help.

Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse. The manufacturer of the machine won't be responsible for sure if you didn't even read the manual… Clear case. That's reality in engineering. If developers want to call themself "engineers" they should behave as such. On the other side you don't let people without special training ev…

Y'know, for some of us peasants, dev work can just be a way out of poverty. We don't have engineering degrees from a top school, we don't work for the FANGs, and we don't work on mission-critical code. The software industry has expanded a lot since the 80s, and now hobbyists can and do make a living out of it even without formal training. So what?

When I started web dev, I earned $15/hr. Beat the $8/hr I was making before that in landscaping. Now I make a little more than that, which still isn't much. My clients/employers don't pay crazy wages and they don't expect crazy quality work. They know they get what they pay for, and it works out for both parties.

Maybe's OK to have shitty, mediocre code for 90% of the world's needs... a small biz website, with the ecommerce/PCI bits outsourced? Sure, why not. It mostly works, and if it goes down for a few hours a year, maybe that doesn't meet super-reliability standards (can we count 8s instead of 9s?) but it gets the job done well enough? Shrug.

Sure, proper engineer techniques matter for certain applications. I would never want to touch industrial machines, or medical, or space, or automobiles... anything that could blow up and/or kill someone. But most code out there is just for some local, small-scale use, mostly temporary anyhow and bound to obsolete in a few years if not months. There will always be mediocre businesses needing mediocre devs for mediocre pay, just as there will be elite enterprises that require the world's smartest people.

Problem is, git was designed by the super smart for the super smart, great engineering with terrible UX. And it was kinda just trickled down to the rest of us, and it feels a bit like trying to teach Mom to use DOS and edit config.sys just to play a game. Now consumer software UX has leaped forward by decades and it shows, but a lot of the command-line dev tools are still incredibly arcane. They don't have to be, but it's not a priority to fix/improve their UX because, I suppose, it's engineers who are proud of their engineering, not proud of their ability to dumb it down for the rest of us. I don't blame them, I just know I can't meaningfully contribute to git (the project) because I'm not smart enough, well trained enough, whatever, and that complaints would fall on deaf ears like yours. It's an altogether different culture. Elitist by design, or meritocratic if you will.

And believe or not, I've probably spent more time learning git -- reading documentation, diagramming it out with coworkers, cloning repos and experimenting with commands, etc., following a shit-ton of tutorials -- than any other skill I've ever had to learn. It was quicker to learn Perl and regex than mid-level git.

If you want to pay for the world's would-be engineers to receive all the training to go from mere dev to proper "software engineers", by all means please do. But otherwise, well... you know what? World's gonna keep producing mediocrity. Most of us are just average.

Re: Git undo: We can do better

#376

Post by fisherjeff »

handrous wrote: post #32
eric4smith wrote: post #12

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…

I know (or, at least, have known ) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the com…

YES! It always seems like people’s issues are handwaved away with something like “oh you just need to understand the underlying data structures better.” No, the UX is often very bad! Like, I know exactly what I want the underlying repo to do, but how the hell am I supposed to remember which —-option of which command is going to do that thing?

Re: Git undo: We can do better

#377

Post by naniwaduni »

still_grokking wrote: post #340
glandium wrote: post #315

Earlier quoted context omitted.

It does delete whatever uncommitted changes you had.

Well, that's the purpose of "reset". You explicitly ask the system to delete whatever uncommitted changes you had. If you type in "rm -rf ." there will also be no "warning" about what happens next… I for my part don't like systems that after giving it a command very explicitly asks me whether it should really execute that command. "You just pressed the button to delete those files. Do you really want to delete those…

> But out of my perspective it's a feature and not a bug that unixy systems traditionally don't ask stupid questions after you told them to do something. It's an attitude of respect towards the operator: The system assumes that the operator knows what he is doing.

By the way, have you ever run across a situation where the standardized behaviour of rm without -f (to wit, check the permissions of each non-directory, and, if it's not writable, prompt if stdin is a terminal)?

Re: Git undo: We can do better

#378

Post by stevenhuang »

thewebcount wrote: post #144
juped wrote: post #76

Earlier quoted context omitted.

Weird, it has no syntax...

I'm not sure what you mean. Typing "git help reflog" brings up a man page that lists commands like "show", "expire", "delete", etc., each with additional options.

Because the most common usage is to run it with no arguments.

Re: Git undo: We can do better

#379

Post by cmeacham98 »

meowface wrote: post #364
sedatk wrote: post #347

Earlier quoted context omitted.

How do people lose their work so easily with Git then?

Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing". On top of this, various git commands can delete things you've done in the working directory w…

They are wrong, there are actions you can take in git that will cause you to lose your "immutable" history. Most accidental cases probably involve `git reset` or `git rebase`, but here's an example if you want to do it intentionally:

    # Commit all changes and push to at least one remote so your changes are ""immutable""
    rm -rf myrepo/
    mkdir example && cd example
    git init
    # Repeat for each remote
    git remote add remote1 https://origin.for/your/repo
    git push remote1 --mirror --force
Congrats, you've lost everything! (Except for your backups, you do have backups right?)

Re: Git undo: We can do better

#380

Post by chefandy »

still_grokking wrote: post #354
unknown_error wrote: post #325

Earlier quoted context omitted.

The point is that you shouldn't have to learn everything by brutal trial and error, losing hours of work each time you try to learn a new operation and make a small mistake. It's the same reason consumer operating systems have a trash can and undo features. Just railing on people with "you should've known better" doesn't really help.

Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse. The manufacturer of the machine won't be responsible for sure if you didn't even read the manual… Clear case. That's reality in engineering. If developers want to call themself "engineers" they should behave as such. On the other side you don't let people without special training ev…

Not a big fan of human factors in engineering, huh?

Documenting poor design rather than improving it is lazy, bad engineering. Requiring rote learning of an very complex interface that poorly represents a moderately complex data structure is lazy, bad engineering. Macho, hyperbolic, gatekeeping arguments for non-design as a design philosophy is advocating for bad engineering. Being mad that people want products with interfaces that make sense is being mad that people want an important facet of good engineering.

Post reply on HN