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

61–70 of 490 posts

Re: Git undo: We can do better

#61

Post by idoubtit »

Simplicitas wrote: post #2

This is an awesome idea. Can't wait to hear the objections from the purists.

I've watched the first case: amend a commit then undo. And I believe it shows serious shortcomings :

- The interactive interface of `git undo` is probably too hard for beginners. Designing simple interfaces is hard, and you can't pplease everyone.

- It seems `git undo` simply does a `git reset--hard` toward a designed commit. The user probably expected to return to the state before the last git action. Instead `git undo` reverted the amend, but also reset the index and remove the local changes. At this point, the beginner could scream "Undo lost my changes! I just wanted a second commit instead of an amend."

Undoing could mean `git reset --hard {hash}`, but in many cases `--hard` would have unwanted effect and the default `--mixed` would be more suitable. But even in this case, it's not a full undo, since the index is not preserved: you don't end up in the same state as before the `commit --amend`.

Re: Git undo: We can do better

#62

Post by arxanas »

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…

There is a design for undoing changes to the staging area: https://github.com/arxanas/git-branchless/issues/10

The similar project [Jujube](https://github.com/martinvonz/jj) has experimented with backing up even unstaged changes after every command, and apparently it works well for them, so we could do the same in the above design.

Undoing even untracked changes might be a bit much.

Re: Git undo: We can do better

#63

Post by disgruntledphd2 »

zibzab wrote: post #50
sebmellen wrote: post #28

Earlier quoted context omitted.

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.

Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know

GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.

Re: Git undo: We can do better

#64

Post by Hamuko »

tcoff91 wrote: post #53
dec0dedab0de wrote: post #45

Earlier quoted context omitted.

I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.

even if you use the git CLI you can still set up a mergetool so that when you are resolving merge conflicts you can use something like BeyondCompare or P4Merge to handle the merge conflicts.

And every Xcode installation on macOS comes with FileMerge.app.

Re: Git undo: We can do better

#66

Post by zabzonk »

zibzab wrote: post #50
sebmellen wrote: post #28

Earlier quoted context omitted.

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.

Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know

The Torvalds effect.

Re: Git undo: We can do better

#67

Post by deeviant »

Filligree wrote: post #44
deeviant wrote: post #10

Earlier quoted context omitted.

If your suggestion for making software better is to make mistakes so punishing that users are thusly properly conditioned to not repeat the mistake then... may I never use software you work on. An analogy in my mind is a "hardcore"(where your in-game character permanently dies if you die once) mode in a game. On the surface, even it's name suggests that a really die hard power gamer is going to want to try this mode,…

> An analogy in my mind is a "hardcore"(where your in-game character permanently dies if you die once) mode in a game. On the surface, even it's name suggests that a really die hard power gamer is going to want to try this mode, the phrase beckons truly a true epic gamer experience that will test the players skill to the utmost. But, you don't get that. You get people getting level 2 by killing only level 1 critters…

Yes, agreed.

I wasn't meaning to be dismissive of those that enjoy or make use of these types of game modes, but really just invoking how hardcore mode ends up on average with the average user for analogy only.

Re: Git undo: We can do better

#68

Post by arxanas »

Jakobeha wrote: post #51

Any other recommendations for CLI tools? I've gotten kind of familiar with the Git CLI. But it took a lot of wasted hours and headaches to do so, and even now it takes headaches and extra time / effort to do certain things like rewrite history and "good" commits. I still prefer CLI to GUI but I wish it was more intuitive.

You should check out the rest of the git-branchless suite mentioned in the article: https://github.com/arxanas/git-branchless. `git restack` is really useful for some of the rewrite cases. There are some other improvements to rewriting in the devel branch.

Re: Git undo: We can do better

#69

Post by handrous »

dheera wrote: post #60
handrous wrote: post #32

Earlier quoted context omitted.

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. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands. And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?

> And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?

This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a pain in the ass.

Re: Git undo: We can do better

#70

Post by OhNoMyqueen »

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.
Post reply on HN