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

401–410 of 490 posts

Re: Git undo: We can do better

#401

Post by pjmlp »

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

Git and Linux go hand-in-hand, so there is your killer use case right there.

Re: Git undo: We can do better

#402

Post by pjmlp »

lugged wrote: post #353
megameter wrote: post #172

Earlier quoted context omitted.

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

This is such a strange attitude to source control as a developer. It's literally the most important tool a developer will use second only to an editor. And again, maybe git is the wrong tool for you, that was kind of my point, use cvs or svn it's much closer to what you seem to want.

If it was so easy, the decision of what SCM platform to use isn't part of the developer teams, rather IT.

Re: Git undo: We can do better

#403

Post by pjmlp »

splicer wrote: post #370
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…

Another: LaTeX

When I was at the university I thought is was cool to do my project reports and thesis in LaTeX, bought all well known reference books, and advocated it everywhere.

Now a couple of decades later, I just use Word or Pages.

Re: Git undo: We can do better

#404

Post by alxndrr »

I am the CTO of Tower, a Git client for Mac and Windows.

Tower for Mac supports Undo (and also Redo) for very much all Git operations starting with version 3 two years ago. This includes undoing all working tree actions like staging/unstaging/discarding individual chunks or complete files. Just hit CMD-Z.

This feature is coming to our Windows version soon as well.

If you're interested in technical details, you can read it here: https://www.git-tower.com/blog/how-we-built-undo/

Re: Git undo: We can do better

#405

Post by arxanas »

alxndrr wrote: post #404

I am the CTO of Tower, a Git client for Mac and Windows. Tower for Mac supports Undo (and also Redo) for very much all Git operations starting with version 3 two years ago. This includes undoing all working tree actions like staging/unstaging/discarding individual chunks or complete files. Just hit CMD-Z. This feature is coming to our Windows version soon as well. If you're interested in technical details, you can re…

Hi alxndrr, I would recommend you improve the SEO for the undo feature. I did a search a while back trying to find Git tools that offered good undo features. When I search for "git tower undo", I get articles about reverting commits and so on, but nothing about "undo anything".

The demo for Undo at https://www.git-tower.com/features/productive/Mac seems to be the wrong demo? It's showing a few lines being discarded, and no undo at all. (And the dialog says that discarding the lines can't be undone...)

Re: Git undo: We can do better

#406

Post by glandium »

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…

> Well, that's the purpose of "reset"

Well, that's the purpose or "reset --hard". "reset" alone doesn't do that. That's the difference with "rm". With "rm" you expect something to be removed. "rm" may fail because you gave it a directory but you forgot "-r". Or it may fail because you don't have the right to the parent directory or something. But it is pretty much expected that something will be deleted if you run "rm".

From the perspective of people who don't understand the difference between "git reset", "git reset --hard", etc., that some of those will destroy their data but not others, is part of the confusion. And when they picked one instead of the other and lose their modifications, they'll blame git from being confusing to use, not themselves for not doing a backup before running a command in their source directory with a program that is used to manage source directories.

Re: Git undo: We can do better

#407

Post by junon »

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…

> Git is an incredibly user-hostile experience, and someone needs to fix or replace it.

* in your opinion.

Re: Git undo: We can do better

#408

Post by marton78 »

alex_smart wrote: post #388
lisper wrote: post #48

Earlier quoted context omitted.

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.

I would if I used Emacs

Re: Git undo: We can do better

#409

Post by cerved »

saiojd wrote: post #363
cerved wrote: post #251

Earlier quoted context omitted.

Git takes stability and extensibility seriously. Your demands and expectations on version control may be radically different from mine. Empty directories do not contain files or information, it's entirely reasonable for a VCS to omit such a feature. Not sure which use case for git is hindered by the inability to check-in empty directories. I would even suggest such a use-case may be a case of DIW

I'm going to be charitable in interpreting your answer, but, if I'm being honest, I find your tone very dismissive... (I would even say, reminiscent of StackOverflow, and not in a good way.) We could easily get into arguments over the specific uses of committing empty directories against the difference it ends up making in terms of stability and extensibility. Instead, consider that: 1) this behavior is very surprisi…

I apologize, that wasn't my intention.

But it's not really surprising that one can't commit empty directories, one can't commit directories at all. Git is a tool for version controlling the lines and bytes of source code under version control. It's a deliberate decision to focus solely on that.

Consider that what is one person's ease of use can be another's pain in the ass. I'm thankful that git has not chosen the path of trying to cater to everyone and their esoteric use cases. I've used other tools that do and it ends up creating a mess instead. Instead it does one thing and it does it well.

I think that if you dig you'll find that if there's something git doesn't do or doesn't do well, that's because a lot of smart people have already looked at that problem and come to the conclusion you shouldn't do things that way.

Re: Git undo: We can do better

#410

Post by npteljes »

u801e wrote: post #390
npteljes wrote: post #207

Earlier quoted context omitted.

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.

My env doesn't do this. Here's what I did:

    git checkout -b test
    git push
And I got "fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test"

But in this situation, we actually push with "git push -u origin branchname".

After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a push, and I got the same error message.

Post reply on HN