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

171–180 of 490 posts

Re: Git undo: We can do better

#171

Post by whalesalad »

whiddershins wrote: post #161

I don't understand. You can always restore any previous state using git, I used to do it from the command line. If I use github desktop I can roll back a commit whenever I like with a simple menu command. What am I missing here. I feel like I don't understand what the tool is doing.

If you understand the fundamentals of a version control system I find git relatively intuitive to use. Sometimes I don’t know the exact cli syntax for a complicated procedure but that’s easy enough to figure out if you know the concepts. Most people fail to learn the concepts and then try to brute force everything.

Re: Git undo: We can do better

#172

Post by megameter »

lugged wrote: post #130
Ensorceled wrote: post #126

Earlier quoted context omitted.

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…

That's nice, but most of us here are version control consumers, not version control professionals. We need something that has very few knobs to turn because our job is focused around delivering value through other tasks.

Git is highly professionalized. It has layers of modal state. That is built into the operating model. It is made for Linus Torvalds, a professional merger of code. If you are using all of those commands "almost daily", you are a professional code-merger too.

Re: Git undo: We can do better

#173

Post by jonahx »

whiddershins wrote: post #161

I don't understand. You can always restore any previous state using git, I used to do it from the command line. If I use github desktop I can roll back a commit whenever I like with a simple menu command. What am I missing here. I feel like I don't understand what the tool is doing.

The README for the parent repo (https://github.com/arxanas/git-branchless) answers these questions in detail.

Short answer, recreating this tool's features in vanilla git requires using the reflog, which isn't user-friendly:

> Why not git reflog?

> git reflog is a tool to view the previous position of a single reference (like HEAD), which can be used to undo operations. But since it only tracks the position of a single reference, complicated operations like rebases can be tedious to reverse-engineer. git undo operates at a higher level of abstraction: the entire state of your repository.

Re: Git undo: We can do better

#175

Post by chriswarbo »

nexuist wrote: post #151
thewebcount wrote: post #128

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

The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this hap…

> It's a human problem

If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows?

> 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.

SVN isn't distributed; it mostly tried to replace CVS, which it managed to do very successfully.

As for DVCS, the fact that system X became more popular than system Y doesn't mean that every aspect of X is better than Y. Many would say git succeeded despite its awful interface. As far as I can tell, the main feature of git was its speed; that made it usable for huge projects like Linux and Xorg, and this endorsement from high-profile projects gave git the edge for DVCS hosting sites like Gitorious. Then GitHub came along, and grew into such a behemoth that git became the de facto standard.

See also: WorseIsBetter

Re: Git undo: We can do better

#176

Post by pjettter »

prisonality wrote: post #164
pjettter wrote: post #123

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

> Git should store the commands that "did" the operations on a repo. is `git reflog` not enough for your use case ?

No, I mean more like an audit trail. Not like `blame` either. What I typed on the command line to get into a new state.

Re: Git undo: We can do better

#177

Post by jonahx »

nsomaru wrote: post #96
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.

Am I doing things wrong if I have never used these commands?

Probably not using git ideally. Do you clean your history after working on a feature?

Re: Git undo: We can do better

#178

Post by daxelrod »

nexuist wrote: post #151
thewebcount wrote: post #128

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

The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this hap…

I agree that collaborative text editing between multiple users simultaneously is hard.

That doesn't mean that Git couldn't have a much better UI for this problem than it does. And while I agree that Git seems to have mostly won over SVN and Hg, it doesn't follow that it's because of its UI. (For example, I think that a lot of Git's success actually comes from the UI of GitHub, not Git itself, but I don't have evidence to back it up.)

Take a look at the Research section at the bottom of https://gitless.com/ for work that's been done on how to accomplish the same operations with a simpler conceptual model.

Re: Git undo: We can do better

#179

Post by umvi »

sedatk wrote: post #125

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

Sounds like mercurial repos would have a lot of "noise" with that approach - commits for fixing other commits spamming everywhere

Re: Git undo: We can do better

#180

Post by seoaeu »

grogenaut wrote: post #58
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.

Personally I think it just needs a 3.0 where they completely rename all the commands so that they're really unified. I know there was pushback on this in the past

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