Live data from Hacker News

Git Undo

megakemp.com

21–30 of 175 posts

Re: Git Undo

#21

Earlier quoted context omitted.

You'd probably really like Magit mode for Emacs then. What you're describing with interactive add becomes trivial since you can stage parts of the diff by selecting them in a region. I can hardly live without Magit these days. Bonus is that it even works on remote hosts via tramp.

With the vim-gitgutter plugin installed, you can dynamically add/remove/undo hunks without even leaving the editor[0]. I use this instead of `git add -p` nowadays [0]: https://github.com/airblade/vim-gitgutter#getting-started

No post body was provided.

Re: Git Undo

#22
post #2

Most git command-lines are lengthy enough to give me time to consider them, so I don't often feel the need to "take back" a git invocation. What I do often screw up, though, is the (almost hypnotic) tapping of y/n when doing a `git {add, reset, checkout} -p` to prepare and clean up a commit. Ideally, with all of the -p commands, git wouldn't actually apply any of the changes I specified until it was about to quit (i.…

You'd probably really like Magit mode for Emacs then. What you're describing with interactive add becomes trivial since you can stage parts of the diff by selecting them in a region. I can hardly live without Magit these days. Bonus is that it even works on remote hosts via tramp.

I can enthusiastically second this recommendation. If you use Emacs and Git, but have not yet tried Magit, you are missing out.

Re: Git Undo

#23
post #5

This seems dangerous to get used to. I always thought the reflog was supposed to be last-resort. Isn't it?

That doesn't sound right. There's nothing secret or internal about the reflog. "reset --hard" is more of a last resort, but only because it wipes uncommitted changes.

Re: Git Undo

#25

Warrants a big warning that using `reset --hard` will irreversibly wipe out any uncommitted changes.

Also doing `git checkout -- filename` will lose the changes to that file permanently. The only feature I miss from Bazaar was that it would create a backup file automatically for its equivalent command. I have actually created a bash function that overrides git to add this functionality (since there is no pre-checkout Git hook and Git doesn't allow you to create an alias named "checkout").

Re: Git Undo

#26

Warrants a big warning that using `reset --hard` will irreversibly wipe out any uncommitted changes.

Came here for this. git undo won't restore the changes wiped out by reset --hard? They aren't stored on the reflog?

If it hasn't been committed, it won't be in the reflog. Working copies and stashed changes are especially vulnerable to being overwritten by accident. It would be great if git had a way to undo these operations too.

Re: Git Undo

#27
post #13

I worry about naming a function undo that doesn't necessarily undo what the user expects. Undo has a strong user expectation, and I'm not convinced this matches that.

Git already has `git branch` which doesn't in fact do any kind of branching but creates a label which follows commits when it's checked out.

You can look at it as a copy-on-write optimisation. It may not be so poorly named if you look at it that way.

Re: Git Undo

#28
I have this alias in my ~/.gitconfig:

    cancel = reset --soft HEAD^
I don't want an alias to hard reset, it seems to dangerous and a good way to lose some work. However a soft reset like this allow me to cancel the last commit and add an omitted file, or remove one from the commit, or simply to correct the commit message easily.

Re: Git Undo

#29
post #13

I worry about naming a function undo that doesn't necessarily undo what the user expects. Undo has a strong user expectation, and I'm not convinced this matches that.

Git already has `git branch` which doesn't in fact do any kind of branching but creates a label which follows commits when it's checked out.

That's all a Git branch is though; so it makes perfect sense for the command `git branch` to do that.

Re: Git Undo

#30
post #19

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?

It's just a way of looking at it. Let's say I'm in charge of a project. You send me a patch. I commit the patch. What I want in my history is that I committed your patch. I really don't care what you did in your history to create that patch.

But it's equally valid to consider all your commits important in my history as well. It just depends on what you want. Personally, I never rebase, but I can understand why some people like that feature.

Post reply on HN