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 Undo
11–20 of 175 posts
Re: Git Undo
#12Nice idea! The only non intuitive thing might be, that calling e.g. 'git undo' twice doesn't undo the last two changes, but the first undos the last change and the second one undos the undo.
Could it be improved to have undo filter out its own reflog entries and instead have a 'redo' to undo those?
Re: Git Undo
#13I 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.
Re: Git Undo
#14Most 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.
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
Re: Git Undo
#15Warrants 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?
Re: Git Undo
#16I find reflog one of the neatest git features, and regularly use it to get out of jail / help cherry-pick across branches. This seems a bit magical, but I think there are some pretty neat lessons within for lots of users which still makes this a great read.
Re: Git Undo
#17Why not just use a filesystem which supports snapshots? It would allow you to go back without even invoking git.
Re: Git Undo
#18Why not just use a filesystem which supports snapshots? It would allow you to go back without even invoking git.
Because a simple, but clever, alias that integrates with everyone's existing workflow is a lot easier?
Re: Git Undo
#19I 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?
Re: Git Undo
#20I 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.
It doesn't immediately make any kind of branch, but if you then create commits using both of the labels it will inevitably create a branch in the DAG so it's not terribly misnamed.