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

121–130 of 490 posts

Re: Git undo: We can do better

#121

Post by eric4smith »

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 do use git every single day. It’s a super valuable tool. Maybe my bad on not taking a course or reading the manual from cover to cover.

Re: Git undo: We can do better

#122

Post by professoretc »

From the article:

> How is it so easy to “lose” your data in a system that’s supposed to never lose your data?

I think the author is mistaken; git isn't "a system that’s supposed to never lose your data". One of its features is the ability to "lose" data in a controlled way; i.e., to rewrite history. If you want a version control that is supposed to never lose data, use Fossil.

Re: Git undo: We can do better

#123

Post by pjettter »

Git should store the commands that "did" the operations on a repo. Git should never ever let you lose work. I should always be able to go "backward" and recover previous states. I guess that is what the "Git undo" proposal is about.

I'm a very visual person so I tend to use Git Graph on VSCode. But I still get in trouble. Especially things like Cherry Picking, or reverting.

Another thing that is not so easy is switching branches without having to do a commit. Stashing, yeah, but then figuring out whether stashes have been applied or not, diffing between branches, picking some changes from a diff.

In the end I stick to some basic commands that don't get me in trouble so that I don't lose half a day to recover my work via Dropbox.

Re: Git undo: We can do better

#124

Post by lisper »

akersten wrote: post #104
lisper wrote: post #89

Earlier quoted context omitted.

Yeah, this barely scratches the surface though. Take branching, which is something you're supposed to be doing all the time. So abstractly, I want to be able to get a list of my current branches, create a new branch, check out an existing branch, delete an existing branch, and maybe rename a branch. I would expect the commands for these operations to be something like: git branch list git branch create [name] git bra…

> Git branch list" is just "git branch". "git branch create" is "git branch [name]". So creating a branch is the SAME COMMAND as the one you use to produce a list of current branches, just with an argument. Madness. And this is the rule, not the exception. As a counter-opinion, I actually like it this way. Especially since it's the rule and not the exception. When one makes the small effort to learn the commands, the…

There's nothing wrong with having a UI for power users in addition to a more intuitive one. But having a power-user UI as the only option (or even as the default) is not so good.

Re: Git undo: We can do better

#125

Post by sedatk »

I think Mercurial is way ahead of Git on this department by having repositories immutable by default, so even undo actions would have their commit. You never find yourself in an unrecoverable situation. Advanced mutable features can only be accessed by making configuration changes, and are still safe to use because public changesets are differentiated from draft changesets, so, you can only make changes on your own work, not anything else. I mean, you can force it, but that comes with its warnings.

Mercurial has no staging area, and that can be inconvenient for some scenarios; but I think no-staging model is easier to grasp for beginners. I especially think many beginners would assume that modifying a file after it's been added to staging area would update staging area automatically too.

Mercurial has high-level, scenario-oriented distinct "undo" commands like "revert", "forget" and "backout" instead of overloading a single command ("reset") for everything.

I still like `git reflog` though.

Re: Git undo: We can do better

#126

Post by Ensorceled »

lugged wrote: post #120
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 come across this attitude a lot. Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education? Do you treat a new programming language or framework with the same disdain? I know I'm gonna get some hate for pointing this out but this same disdain is what causes things like the branchless workflow. A…

At one time I was an expert in 'C'. I was the goto guy at our company for porting and performance issues and was often just handed the entire project if it involved porting.

I have no memory of any of that beyond the basics now. Git is like that. There is no way I will remember commands I only use once a quarter or so when something goes wrong.

Re: Git undo: We can do better

#127

Post by overgard »

pizza234 wrote: post #37
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…

Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.

I find GUI's to be very helpful; most of my commits happen through VSCode's commit panel. For my home Unity3D project I use sourcetree because my commits unfortunately end up being to a lot of unrelated files (blame unity), and having a UI to stage them saves a lot of typing. I avoid anything like rebasing (never got the point of that), but I use branches liberally. I find with this setup, I only need to use a handful of command line options, and I haven't screwed up a local repository in a long time.

Re: Git undo: We can do better

#128

Post by thewebcount »

I'm sorry, but how many bits of git's UI do we have to force users to manually replace before we realize that the entire problem is git's UI?

Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certainly one of the problems). Git is an incredibly user-hostile experience, and someone needs to fix or replace it. Can we just say it out loud and stop pretending that the problem is the literally thousands of users who have problems using it?

Re: Git undo: We can do better

#129

Post by renewiltord »

It is interesting. I’ve never had any trouble with git. I think the reason is that I learned it relatively early in my career and so I had the luxury of “What’s the right way to resolve this situation?”. I have never lost data despite using filter-branch, rebase, bad merges, bad rebases, bad branch deletes…

Still, the UX sugar of undo sounds quite nice. I only worry about introducing something heavyweight into the thing. If I use branchless will it force others to use branchless too?

Re: Git undo: We can do better

#130

Post by lugged »

Ensorceled wrote: post #126
lugged wrote: post #120

Earlier quoted context omitted.

I come across this attitude a lot. Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education? Do you treat a new programming language or framework with the same disdain? I know I'm gonna get some hate for pointing this out but this same disdain is what causes things like the branchless workflow. A…

At one time I was an expert in 'C'. I was the goto guy at our company for porting and performance issues and was often just handed the entire project if it involved porting. I have no memory of any of that beyond the basics now. Git is like that. There is no way I will remember commands I only use once a quarter or so when something goes wrong.

I don't know what to tell you, commit more code? Branch more? Work in teams?

Maybe git isn't the right tool for you?

I have a set of commands I use multiple times a day, for everything else there are manuals and docs to reference.

Git branch, commit, rebase, merge, clone, check out, pull, push, submodule, remote, and maybe a couple more, are there specific commands you don't use daily? Other than remote and submodule I use all of those almost daily.

Post reply on HN