Git Undo (opens in new tab)

Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain.

At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos.

On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt.

Most mortal programmers need the ability to iterate over their code to get it to a reasonable place before they want it enshrined in the blessed commit history that is shared with others or otherwise retained over time. The intermediary states, with false starts, poor implementations, hand crafted functions instead of standard functions, poorly named classes, and so on are all part of development but aren't particularly interesting to keep in the permanent history of a project.

Git's ability to manipulate the existing commit tree (amend, reset, rebase, etc.) is extremely useful for this normal 'exploratory' development. Once a stable point has been reached though (often because the tree has been published or shared with others), these commands do become inappropriate and a different set of tools becomes relevant (revert, merge, etc.).

You might want to have `git bisect` working, for instance. For bisect to be useful, each commit should leave the repo in a consistent, "green" state. If you commit something stupid by mistake, and add a commit later to fix it, then during the bisect you might get wrongly stopped at the stupid commit.

Arguably it's more important to have clean commit history in open source projects. I used to be hard on this at work but I relaxed a bit lately.

Generally the development in companies moves much faster than in open source libraries (in terms of # of commits per weeks), and generally in open source world it's expected to have clean, well tested, working solutions rather than hacks that can be fixed tomorrow if needed - and because of that, OS maintainers have higher standards for commits.

There seems to be a split among git users between those who think history should show what actually happened (i.e. it's left alone), and those who think history should tell a story about the changes (i.e. once you've finished something, turn it into a coherent set of commits like "stub out X", "add tests for X", "make first X test pass", etc.).

I agree with you, that history should be left alone; mostly I think of the YAGNI argument that its futile to think that you have a better idea of what future developers want to see, compared to those future developers themselves.

My repo histories are riddled with stuff like "finished X", "stubbed out Y", "fix typo in X", but at least nothing has been hidden from future devs who might be digging around for their purposes, regardless of whatever elegant story I might come up with.

Many people think that for later reference a history where each commit contains exactly one feature or bugfix is more useful than the usual development workflow of "start feature a, fix bug in related feature b, fix documentation of unrelated startup flag, implement feature c that turns out to be prerequisite to feature a, do more work on feature a, fix bug in c, [...], finish work on a".

And in case you want to commit to an open source project you are basically forced to rewrite history for any non-trivial change because changes that make sense to develop at the same time often form independent PRs.

You have to think about the purpose of the history.

Git history serves a few purposes. First, it provides an overview of development so that someone can use `git log` to quickly figure out what's been done. Second, it provides context to code changes so that someone using `git blame` can figure out why some code looks the way it does. Finally, it provides a set of distinct points for clean manipulation of history via `git revert`, `git bisect` etc.

From the point of those purposes, there's no real value in a history which accurately reflects the development process. The ideal commit has a few properties: it should address only one concern, it should contain all the immediate code changes addressing that concern, and it should not be overly long. Commits like that make navigating and manipulating the git history easy.

There's nothing wrong with keeping an accurate picture of history. It's just not actually useful.

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.

I never had the urge to rewrite the history of my code until I started using CI & CD. Since then, it happened to me few times that I wanted to fix something small and ended up trying multiple times, pushing a new "maybe this time?!" commit over and over again. Obviously it's not best practice, but it something you do when there's a rush.

Having 10 tiny commits like that are just failed attempts to fix a bug isn't practical. It makes reading and understanding your repository code _harder_. Git rebase helps me keep my log clean and understandable, thus making it something I can work with in the future.

There can definitely be value in e.g. summarizing the final result and understanding after a number of 'failed' iterations. And that the many small commits can be considered "noise" if you only care about what happened at a high level. However, rewriting history with operations like squash or rebase IMO seems like a bad solution to a real problem - it really shows that we don't yet have the right abstractions or tools for doing this. If all the small commits are considered "noise" then it shows that we don't have good enough tooling for filtering and grouping when perusing our VC history. The information that people are currently putting into a squash commit is an aggregate or derivative of the original, and as such shouldn't replace it, it should supplement it. There are legitimate use cases where the details of those small commits are indeed valuable, even if the more high-level "just tell me the final result" use case is more common - you shouldn't have to be forced into making that tradeoff.

I know some people are using merge commits or pull requests as a place to put this information - but maybe we need a an explicit mechanism for grouping together commits and summarizing them? I'm imagining something along the lines of code folding. Such a grouping might have other uses too (e.g. signal that there's a grouping of commits where the tests will fail, so skip to the last commit if bisecting)

I too admit that I'm a huge Hg fan (will not switch the company code to git) but I also admit history rewriting is a damn worthy feature. At the very minimum I think we can agree that safe rebasing is better than a plethora of merges that really serve no purpose other than to clutter history. The more distributed and diverse/disparate your team is the more I think history editing + cheap branching is worthwhile (but on the opposite end I think Hg consistency is better for corp).

One of my greatest challenges in using/understanding Git was(/is still) the reflog. I know the reflog isn't that complicated but there isn't anything really analogous in other SCM (of my limited knowledge of perforce, svn, hg, git). Also for some reason the presentation of the reflog UI wise is intimidating.

Reflog is nice gem for git particularly since the builtin Mercurial rollback (I wish they would just remove that command) is fairly awful (use histedit or rebase instead). That being said Mercurials new changeset evolution experimental stuff looks really promising [1].

That being said if you are looking to undo in hg like this article talks about you have to look at the

    hg unbundle backupfile

Unbundle is a pretty nasty command compared to the reflog commands but on the other it is just restoring from some backup file. I'm not too sure how you can transfer reflogs around.

[1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution

What does accurate history mean?

Do you commit after every 20 seconds of typing?

Why not?

The people cleaning up history have the same motivation.

> What's so wrong with keeping an accurate picture of history

I think part of the problem is the distinction between history and audit. What you are thinking of is a full audit: every change made by everyone to get to and from each state.

History can sometimes be this, but sometimes you just want the solid states and the extra detail of each step between including failed steps that were back-tracked is more information than people want and can result in cognitive overload.

Different people want different detail.

Sometimes the same people want different detail for different tasks. One option might be for a feature to allow you to mark a commit as intermediate. Keep those with the flag around but don't display them or allow things like bisect to operate on it by default. Display them if an extra option is provided, allow action upon them similarly (not by default, you don't want a typo in a commit ID to result in a commit that exists but is not the one you are looking for to be accessed).

In my opinion, it is only valuable to present a pristine history to make sure that every "official" commit provides an application that can be ran. This allows git bisect to do amazing things. In other words, I will git merge --squash. When someone rewrites history after pushing, all they do is make everyone else have a bad day.

No version control system accurately reflects every bit of history that goes into creating and editing your code. You'd have to record every keystroke. The whole idea behind a vcs is to record helpful and relevant history. Is every little merge relevant and helpful history? Hard to say, maybe, but probably not.

It's the same reason that history books aren't a bunch of primary sources stapled together.

What more better than painstakingly accurate history is useful history. I don't care that Joe was distracted one day and had to make a fix-up commit. I care that he authored a certain change.

I'm also coming from Hg, and this picture [1] sums up the problem. The history tree in our company is way more messy - basically over 1/3 of all commits are just merges.

[1] https://twitter.com/michaelhenke/status/585142133167751169

> 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?

What's wrong with organizing your source code in a single directory? Why do people insist on organizing them into subdirectories aud subsubdirectories instead of letting the main directory accurately reflect the size of the code base?

How do you accurately reflect the history of development when it's nonlinear?

I was an hg person too, but I came over to the git side when I needed to collaborate with people. git's killer feature is merges. And merges benefit from fine-grained commits that rewrite history.

The basics (stage, commit, merge, branch, push, pull, log, diff, bisect) aren’t confusing. (The rest isn’t that confusing either, but…) If you prefer GUIs, feel free to use them, but that’s certainly not everyone.

I teach Git. I find many who have learned just enough to get by, and their shallow understanding hobbles them.

It's not enough to memorize command line "incantations", you have to understand what's happening.

Git is a sophisticated tool. There are over 100 subcommands!

Once you fully understand the basic terms (e.g., "detached", "HEAD", "branch", "commit", etc.) Git becomes less confusing.

http://www.verticalsysadmin.com/git/flyer.html describes a free webinar we offer on Git basics -- people who have used Git for years come away surprised how much they've learned.

It's the "boil the oceans" problem (http://www.urbandictionary.com/define.php?term=%22boiling%20...). Same thing that happens with vi, for example.

You have a widely adopted tool with some real or perceived flaws. Everybody knows them and wants to fix them.

But unless you somehow get mass adoption from the start, the project flounders because everyone will be pointing out that you can't install & use the new tool in restricted environments or on very old environments.

So we're left with the lowest common denominator.

At this point, to break the cycle, either the original developers come with the 2.0 interface and push it hard (which might cause backlash: https://xkcd.com/1172/) or someone with a ton of pull and resources does it from outside (which could trigger a fork or other unpleasantness).

One can argue semantics whether you call it a UI or a CLI, but hey. There's a number of GUI clients out there that depending on your criteria could be considered better. They're usually not as powerful as the CLI client though, and if they are, features like accessing the reflog are hard to find and use. There's also a few alternative CLIs out there, I've just done a quick googling and came across http://www.saintsjd.com/2012/01/a-better-ui-for-git/ and http://www.kennethreitz.org/essays/legit-the-sexy-git-cli.

Personally I prefer the CLI, it's the only tool that I can rely on to do what I tell it to do and to know what's happening. But it takes time and effort to get used to it.

> I'm surprised we're not all using a better frontend by now.

Chalk that up to the power of fashion and a misguided notion of technical proficiency.

Once you understand Git's data model, the UI is perfectly intuitive and very efficient. When you want to do something in git, it generally requires just a single command - you just have to know what you actually want to do.

Attempts at different UIs fail because they're all trying to put an abstraction over top of git that doesn't actually reflect the underlying data. As a result, they're limited to the set of git functionality that overlaps their abstraction, and the tools are less powerful.

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. </emacs plug>

As long as its not the last one, you can go back with `K` to the previous hunk. And forward with `J`. (The lowercase versions only go to hunks you decided to skip, but uppercase go to all, even ones you already chose an option for)

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.

Actually, if that's all you want, you can do:

  git add <file>
  # or "git rm --cached <file>" to remove
  git commit --amend

and it will replace with a new commit that has what you want. It's like a mini rebase -i

Yep, git gives you more than enough rope to hang yourself with.

Could it be improved to have undo filter out its own reflog entries and instead have a 'redo' to undo those?

I agree with that. So you could undo step by step without thinking about the number to put next to your undo command. It seems a bit trickier to implement, though

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").

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

So what happens when two developers edit the same file, or make changes to different files that in combination break the system?

You need commits, you need the ability to merge. If you don't want to force all commits to happen online and everyone to resolve conflicts immediately then you need branches. You want tags if you're going to have releases (otherwise how do you refer to them?). At that point you basically have git.

All the complicated features were added because someone thought they needed them (there are certainly a few git features where I think that someone was wrong, but not many).

If that's what you want, you can just use Dropbox itself to store code and use one of the several deployment tools which can pull code from it (e.g. cloudcannon).

It quickly falls apart though as you don't have a proper history, reverts, or branching - it's OK for static sites but a disaster for anything more than that.

Have you ever tried subversion?

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.

Granted, you can shoot yourself in the foot with cp(1), but not nearly as much as git(1) lets you.

Why not just boil the ocean?

Because a simple, but clever, alias that integrates with everyone's existing workflow is a lot easier?

1. calculating differences

2. merging two or more different branches

3. transporting code (publishing it)

3a. accepting somebody else's patches

4. descriptions of history points

4a. pointers to parent code trees (especially with tree merges)

5. history traversals (bisecting, among the others)

Not to mention that you need either administrative privileges for creating a snapshot or a special kind of filesystem that supports this for non-administrator. And sysadmin still needs to prepare such a filesystem for your $HOME.

That was called : ClearCase.