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

301–310 of 490 posts

Re: Git undo: We can do better

#301

Post by atoav »

lisper wrote: post #89
arxanas wrote: post #62

Earlier quoted context omitted.

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.

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…

Checkout should be load or open.

Re: Git undo: We can do better

#302

Post by cerved »

dorian-marchal wrote: post #279
cerved wrote: post #224

Earlier quoted context omitted.

Commits are immutable, itś incredibly hard to destroy data that has been committed. Even if they become loose objects, Git is very conservative when it comes to deleted that. If you have uncommitted data, git will refuse to do lots of operations. The default is always to not delete changes, even if resetting a branch. Contrast that with TFVC which tries its best to nuke everything within it's reach (that is not under…

Unfortunately, it is still very easy to lose data, e.g. by trying to undo a temporary commit with `git reset --hard HEAD^` (note the --hard option) before committing your changes.

That's why it's a flag. You could do git reset HEAD^ && git stash instead

Also, git reset ---hard HEAD^ deletes nothing. The commit HEAD was pointing is not deleted. You have to work really hard to delete that commit accidentally

Re: Git undo: We can do better

#303

Post by zoomablemind »

handrous wrote: post #32
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 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…

I wonder should Undo as a concept apply to all Git actions/commans which have state side-effects on the repo or work dir OR should Undo only cover certain operations (which ones)?

Re: Git undo: We can do better

#304

Post by mdaniel »

rjmunro wrote: post #201
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…

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…

> But `git checkout filename` means "undo changes to the file". What? That's totally insane.

Heh, and I'll do you one better: it's unstaged changes, so it won't put the file back to the HEAD version 100% of the time >:-)

Re: Git undo: We can do better

#305

Post by secondcoming »

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…

Apache is popular because writing a fully spec compliant HTTP server is actually quite difficult. We use it, I don't like it, but I have enough experience with HTTP to know to not write my own implementation, especially in C/C++.

Re: Git undo: We can do better

#306

Post by secondcoming »

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…

hunk?

Re: Git undo: We can do better

#307

Post by gumby »

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…

> tone deaf responses of "you just have to learn it's internal architecture,"

Why is this tone deaf? It’s a development tool for programmers and the internal structure is conceptionally pretty straightforward. Understanding your tools is pretty much prerequisite. You don’t have to have written a compiler to use one, but you do have to have a model of what it does. Git is no different.

Re: Git undo: We can do better

#308

Post by symlinkk »

seoaeu wrote: post #180
grogenaut wrote: post #58

Earlier quoted context omitted.

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.

It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.

Re: Git undo: We can do better

#309

Post by Shacklz »

lanstin wrote: post #228
MereInterest wrote: post #211

Earlier quoted context omitted.

> that identical changes in two branches are not actually a conflict I think this is part of a downside of rebase-centric workflows, since it encourages making multiple branches with identical changes, but no shared history. At some point I want to read more pros/cons on different workflows. My current thinking is that rebase-only sacrifices far too much on the altar of a clean-but-inaccurate commit history, but I do…

I think if you run into this a lot, git revere will be helpful: https://www.git-scm.com/book/en/v2/Git-Tools-Rerere If you have a lot of long-lived branches that don't merge and get deleted you have a whole different world of pain from normal git usage, and need some resources designed as SCM experts to manage this stuff. But really short lived branches that deliver net steps forward are the way to live. I hate branc…

> Linux kernel history has lived without it, so I'm guessing the "our code is so complex we need it" is a false idea.

Those guys are still sending commits (patches) to each other by mail, I think they willingly live in such a special and weird bubble that it just can't be compared to any "real life industry project".

We've recently started to enforce linear history on our main branches at work, because it makes analyzing broken builds such a breeze. The mantra is "Insertion is hard, analyzing/understanding is easy" (for a merge-based history, it's pretty much the other way around), and so far it's quite the success.

It did take quite a bit of effort though to get everyone up to speed, and it still requires the occasional help to clean up the commit history of some merge request, but it was well-worth the trouble so far.

Re: Git undo: We can do better

#310

Post by cerved »

AlexSW wrote: post #282
dorian-marchal wrote: post #279

Earlier quoted context omitted.

Unfortunately, it is still very easy to lose data, e.g. by trying to undo a temporary commit with `git reset --hard HEAD^` (note the --hard option) before committing your changes.

Agreed. I consider myself pretty competent at git (consistently helping out the rest of my team of ~15 people with it) and even then I've shot myself in the foot using `git checkout --` instead of `git reset` before to unstage a file, and lost all of my work on it. Really felt that should have given a warning.

use git stash instead to unstage changes not committed to the index and you'll never lose anything ever again
Post reply on HN