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

381–390 of 490 posts

Re: Git undo: We can do better

#381

Post by chefandy »

unknown_error wrote: post #375
still_grokking wrote: post #354

Earlier quoted context omitted.

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 b…

As long as there are people who create things for others to use, there will be people who blame users for not being technical enough to work around their lack of ability or willingness to produce good interfaces. Developers just happened to also be the users in this instance.

Re: Git undo: We can do better

#382

Post by seoaeu »

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…

Humans make mistakes. Well designed systems are resilient to those mistakes. That doesn't mean prompting after every single command, which as you point out would be super annoying, but it does mean making operations reversible unless there is a very good reason they cannot be. Essentially every system designed in the last few decades has a concept of a 'recycle bin' or undo feature for deletions at least for a short window of time.

Re: Git undo: We can do better

#383

Post by bedobi »

A huge reason why undoing things in Git get needlessly confusing is using merge commits in the first place. I've always advocated ONLY squash commits to master. It makes things much, much easier to understand, and much, much easier to undo things with equally easy to understand regular git reverts.

Re: Git undo: We can do better

#384

Post by seoaeu »

kahkeng wrote: post #222
OhNoMyqueen wrote: post #70

The most painful mistakes beginers endure with git are irrevocable code removal from the current working directory because of bad usage of `git clean`, `git reset` (or `git merge` if you're brutish enough). This problem cannot be solved by using git, because git doesn't have any reference to such code.

I find it pretty useful to use the `--patch` or `-p` option (also a mnemonic for "prompt") to various commands: `git add -p`: prompt which hunks should be added to staging `git checkout -p`: prompt which unstaged hunks should be thrown away `git checkout HEAD^ -p`: prompt which hunks from HEAD should be discarded `git reset -p`: prompt which currently-staged hunks should be unstaged `git reset HEAD^ -p`: prompt which…

Frustratingly `git add -p` adds a new and exciting way to accidentally lose "work": You can type `git commit -a` and all of a sudden all your manual selections of different hunks to include/exclude are irreversibly gone

Re: Git undo: We can do better

#385

Post by girishso »

arxanas wrote: post #35
girishso wrote: post #3

This seems like a very good idea. Only if we can scroll through the commit hashes and see the preview of commit with help of fzf or something similar, it will be totally awesome.

I would like to add fzf-style interfaces to checking out more things. Hopefully, they could index both the commit message and the commit contents when searching.

Totally possible, I've following helper in my .zshrc

  # fshow - git commit browser
  fshow() {
    git log --graph --color=always HEAD \
        --format="%C(auto)%h%d %s %C(blue)(%aN) %C(black)%C(bold)%cr" "$@" |
    fzf --ansi --no-sort --reverse --tiebreak=index --bind=ctrl-s:toggle-sort \
        --bind "j:down,k:up,q:abort,ctrl-m:execute:
                  (grep -o '[a-f0-9]\{7\}' | head -1 |
                  xargs -I % sh -c 'git show --color=always % | less -R')

Re: Git undo: We can do better

#386

Post by girishso »

max_hammer wrote: post #7
girishso wrote: post #3

This seems like a very good idea. Only if we can scroll through the commit hashes and see the preview of commit with help of fzf or something similar, it will be totally awesome.

I use maggit and can scroll commit log using `ll` You can also try `lazygit` it's a TUI written in Go

lazygit offers undo like OP's command? I don't think so. What I meant was Git undo displays a list of commits, I would like to see those commit's contents as well, we can do it with fzf.

Re: Git undo: We can do better

#387

Post by kingaillas »

workethics wrote: post #285

I feel like an outcast after reading all the comments here. I've never really had issues using git. I didn't realize so many people had trouble with it.

Meanwhile, I refer to Git Flight Rules (https://github.com/k88hudson/git-flight-rules) on a weekly basis. Especially the branches section - somehow I'm checking in or pulling from the wrong branch, or branching from the wrong parent, and cleaning up is so tedious/annoying. I'm gonna check out this "git undo" command in the article.

Re: Git undo: We can do better

#388

Post by alex_smart »

lisper wrote: post #48
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 understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical chan…

>The plumbing is great. The porcelain is cracked and mildewy.

You might enjoy using Magit.

Re: Git undo: We can do better

#389

Post by Griffinsauce »

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…

> 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.

We are discussing designing the machine in a way that removes these options altogether.

This is objectively and obviously a better strategy because humans are fallible, even when well trained, and the time put into safety training can now be put into an actually productive direction.

You're working from the perspective that machines and git must be dangerous to be effective. This is an assumption that should be challenged before the enormous waste of safety training is accepted.

Re: Git undo: We can do better

#390

Post by u801e »

npteljes wrote: post #207
rjmunro wrote: post #201

Earlier quoted context omitted.

There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine. But `git checkout filename` means "undo changes to the file". What? That's totally insane. `git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you u…

And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.

Are you referring to the git branch command? As far as I'm aware, you don't have to specify the name of the remote branch when creating a new local branch. And when you push to the remote, a branch with the same name is created by default. You would have to specify the remote branch name when running git push if you wanted a different name for the remote branch.
Post reply on HN