25 ms·

Git undo: We can do better

762 points by arxanas 5y ago

Simplicitas 5y ago
This is an awesome idea. Can't wait to hear the objections from the purists.
- idoubtit 5y ago
  I've watched the first case: amend a commit then undo. And I believe it shows serious shortcomings : - The interactive interface of `git undo` is probably too hard for beginners. Designing simple interfaces is hard, and you can't pplease everyone. - It seems `git undo` simply does a `git reset--hard` toward a designed commit. The user probably expected to return to the state before the last git action. Instead `git undo` reverted the amend, but also reset the index and remove the local changes. At this point, the beginner could scream "Undo lost my changes! I just wanted a second commit instead of an amend." Undoing could mean `git reset --hard {hash}`, but in many cases `--hard` would have unwanted effect and the default `--mixed` would be more suitable. But even in this case, it's not a full undo, since the index is not preserved: you don't end up in the same state as before the `commit --amend`.
  - arxanas 5y ago
    There is a design to address undoing changes to the index: https://github.com/arxanas/git-branchless/issues/10 https://github.com/arxanas/git-branchless/issues/10 It runs a `git checkout`, not a `git reset --hard`, so it will stop you if there are incompatible changes. Of course, if `git undo` can be made to lose your staged or unstaged work, then that's a bug. Fortunately, you can undo the result of any `git undo` with another `git undo` that goes one more step back in time.
  - spicybright 5y ago
    Why is it so hard to implement a git undo? You have a previous state, and a current state. Just roll it back.
- RichardCA 5y ago
  The purist will say: You are always free to write your own porcelain.
girishso 5y ago
This seems like a very good idea. Only if we can scroll through the commit hashes and see the preview of commit with help of fzf or something similar, it will be totally awesome.
- max_hammer 5y ago
  I use maggit and can scroll commit log using `ll` You can also try `lazygit` it's a TUI written in Go
  - zhynn 5y ago
    I have been using lazygit for about six months, and I love it.
  - girishso 5y ago
    lazygit offers undo like OP's command? I don't think so. What I meant was Git undo displays a list of commits, I would like to see those commit's contents as well, we can do it with fzf.
- arxanas 5y ago
  I would like to add fzf-style interfaces to checking out more things. Hopefully, they could index both the commit message and the commit contents when searching.
  - girishso 5y ago
    Totally possible, I've following helper in my .zshrc # fshow - git commit browser fshow() { git log --graph --color=always HEAD \ --format="%C(auto)%h%d %s %C(blue)(%aN) %C(black)%C(bold)%cr" "$@" | fzf --ansi --no-sort --reverse --tiebreak=index --bind=ctrl-s:toggle-sort \ --bind "j:down,k:up,q:abort,ctrl-m:execute: (grep -o '[a-f0-9]\{7\}' | head -1 | xargs -I % sh -c 'git show --color=always % | less -R') << 'FZF-EOF' {} FZF-EOF" }
sombremesa 5y ago
> Here’s my theory: novice and intermediate users would significantly improve their understanding and efficacy with Git if they weren’t afraid of making mistakes. Here's something that happens when people are encouraged to make more mistakes: they make more mistakes. The piece where people are encouraged to learn from these mistakes is missing from the author's equation. Without that, this tool becomes a crutch at best, and a disaster waiting to happen at worst. Can we do better? *Edit*: Let me answer my own question. We can do better - for example - simply by adding the Git commands this program would run, aside from the human readable explanation. Not sure what people replying to this comment were aiming for, since they clearly did not offer up a single suggestion. Let me go a bit further and add that self-righteous soapboxes are NOT a good thing, and as it stands none of the replies to this comment were relevant. I was hoping to spark a discussion of what else could be done to improve the experience, but I could have worded my comment better. On the other hand, you can do better.
- _jal 5y ago
  Perhaps it should have been stated outright, but the operative theory appears to be that if mistakes cost less, making more of them becomes the learning exercise.
  - deleted 5y ago
    [deleted]
- yoz-y 5y ago
  I wouldn't be so harsh. I don't know a single program that was made worse by adding undo. Imagine a painting program without it. (I'm sure there are some artistic programs that do that but those would be mostly toys) Trying to learn from mistakes that can be solved by an undo on local repository are mostly in the realm of "be more careful", which is an impossible requirement to achieve in general.
  - shadowgovt 5y ago
    The cost of adding undo is usually the cost itself (i.e. every operation the program can do must now be considered for its reversibility). Not every program justifies that cost, but I have also never seen a program that was made worse by adding it.
max_hammer 5y ago
How hard is `git reflog` `git reset --hard <SHA of commit you want >` Or if you just want to move back 1 commit `git reset HEAD@{1}`
- leifg 5y ago
  git reflog is hard enough so that I (a software engineer for 12 years and a git user for 10+ years) have to look up its syntax every time I need it.
  - SamBam 5y ago
    Can you explain what's tricky about it? For me, I just had to remember that "reflog" was the name for "history." Once I did that, everything else is just regular git commands. Check out a "commit." Revert to a "commit."
  - amelius 5y ago
    I think this is the problem with any command which you only need once in a blue moon. I always forget how to set up networking, because I don't do it often enough.
  - juped 5y ago
    Weird, it has no syntax...
    - thewebcount 5y ago
      I'm not sure what you mean. Typing "git help reflog" brings up a man page that lists commands like "show", "expire", "delete", etc., each with additional options.
      - stevenhuang 5y ago
        Because the most common usage is to run it with no arguments.
  - mattkrause 5y ago
eric4smith 5y ago
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 implications? We don't really know. I feel stupid. But hey, at least I'm honest.
- sebmellen 5y ago
  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.
  - zibzab 5y ago
    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
    - disgruntledphd2 5y ago
      GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.
      - zabzonk 5y ago
        Bitbucket used to provide free (and pretty good) Mercurial hosting.
        oblio 5y ago
        Bitbucket had a much crappier UI.
voiper1 5y ago
Reference to a helpful wizard for fixing your git mistake: http://sethrobertson.github.io/GitFixUm/fixup.html http://sethrobertson.github.io/GitFixUm/fixup.html
- Egoist 5y ago
  Wow, probably one of the best guides i have seen for git. Wish i knew this existed when i was a beginner
- swyx 5y ago
  i can’t believe nobody has mentioned https://ohshitgit.com https://ohshitgit.com so here i am to mention it
amelius 5y ago
Would this work on a pull from a remote? Or how about after pushing to a remote?
- arxanas 5y ago
  Pull from a remote: yes, it will rewind the local references to their old positions. Push: sadly, no.
zach_garwood 5y ago
This seems like putting a training wheel on a training wheel. git is already the easiest to understand of any VCS that I've used, and it's somewhat hard to do something in git that can't be reversed. As the articles states, it's unlikely you'll ever lose your changes. Further, this doesn't seem to be that different of a concept from git reset, so why not learn reset instead of yet another command?
- simias 5y ago
  Hard disagree, git's docs and UI have improved over the years but every time I have to teach it to a beginner I realize how arcane and scary it is, especially when compared to old school centralized VCSs like subversion. Not that I'd trade git for subversion mind you, in the hands of a trained individual git is a godsend, but the training part can be arduous. Even among DVCSs I'd argue that mercurial for instance is vastly easier to pick up.
  - zach_garwood 5y ago
    If it's an issue of having to read the docs or the man, well I've been at work like this for a little over a decade and I still have to pull up a reference when I want to do something nontrivial in, not only git, but pretty much every cli tool I use on a regular basis. Cli tools, frameworks, libraries, languages... I have to pull up a reference for everything I do as a programmer, so it's hard for me to muster up the indignity for having to look up how git works. If it's a matter of understanding the flow of the tool, then I will have to concede that mercurial probably is easier to understand for the beginner.
    - rileymat2 5y ago
      `git add <file>` Wait, how do I remove it from staging? It seems there should be some symmetric operation, `git remove <file>` or something. Maybe git rm `<file>`, whoa don't do that. No, it is `git reset HEAD -- <file>`. There is no mental symmetry. Or why use add at all? What am I adding it to? It is so generic, why not `git stage file` and `git unstage file`? I agree that you need to read and learn tools, but there is a lack of consistency and symmetry in many of the commands which make it harder.
float4 5y ago
> novice users are terrified of it. When they make a mistake, many would rather delete and re-clone the repository than try to fix it In my experience most beginners use a GUI like Atlassian Sourcetree or the Github desktop client. It's a lot harder to make mistakes using the GUI in my experience. I still really like this idea though; eventually a subset of the beginners wants to learn the git cli and that sure seems scary at first.
- arxanas 5y ago
  GUI tools are a great step forward in my opinion, not because the GUIs are necessary, but because the Git command-line interface is really terrible. I would like to see a GUI adopt these concepts. There's no reason why we should limit the commit graph display to only the current time, when we have enough information to scroll through its past states as well.
- lukeinator42 5y ago
  I really love the Jetbrains GUI built into their IDEs for this.
- Osiris 5y ago
  For JetBrains users, there is a built-in Git GUI as well. It's not as easy to use as SourceTree, but since there's no SourceTree for Linux, it works well enough.
- jahnu 5y ago
  Can I give a shout out to Fork here for being another great GUI for git. I'm not affiliated with them in any way. Just a happy customer. https://git-fork.com/ https://git-fork.com/
  - dewey 5y ago
    Agreed, another happy Fork user here. I switched from Tower as it just got more and more expensive and added features I don't need.
- contriban 5y ago
deleted 5y ago
[deleted]
Jakobeha 5y ago
Any other recommendations for CLI tools? I've gotten kind of familiar with the Git CLI. But it took a lot of wasted hours and headaches to do so, and even now it takes headaches and extra time / effort to do certain things like rewrite history and "good" commits. I still prefer CLI to GUI but I wish it was more intuitive.
- arxanas 5y ago
  You should check out the rest of the git-branchless suite mentioned in the article: https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless. `git restack` is really useful for some of the rewrite cases. There are some other improvements to rewriting in the devel branch.
- jph 5y ago
  Git Alias has many: https://github.com/gitalias/gitalias https://github.com/gitalias/gitalias
- jgilias 5y ago
  There's tig: https://jonas.github.io/tig/ https://jonas.github.io/tig/ It doesn't have too many features, but the main thing it aims for - a better repo browser, it does really well in my opinion.
  - qq4 5y ago
    I can second tig, it really helps me parse the repo.
- sensanaty 5y ago
  I like forgit a lot, been using it for a while https://github.com/wfxr/forgit https://github.com/wfxr/forgit
optymizer 5y ago
This is an excellent idea and I'm glad it's making its way into the open source community. My company has an equivalent to 'git undo' that basically undoes anything you just did to your local repo. It's just so freeing. Sometimes you need that Ctrl+Z so you can undo and redo things correctly. It gets your mind back to whatever you were doing before without needing to debug wtf just happened.
noxer 5y ago
obligatory mention of fossil-scm.org just in case someone don't know yet and would like a version control system++ that actually works for/with you.
OhNoMyqueen 5y ago
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.
- juped 5y ago
  Also from deleting their whole checkout.
- nsomaru 5y ago
  Am I doing things wrong if I have never used these commands?
  - jdauriemma 5y ago
    Try not to think of it in terms of right and wrong. `git clean` is useful, though not "can't-live-without-it" useful. I couldn't imagine my workflow without `git reset`, though, and I recommend checking it out!
  - jonahx 5y ago
    Probably not using git ideally. Do you clean your history after working on a feature?
  - rjmunro 5y ago
    No, IMHO you are doing things right. I virtually never use those commands, I've been using git for well over 10 years, and have totally got used to all it's quirks.
- anamexis 5y ago
  I agree, these are the only times I've irreversibly gotten myself into trouble. I think it would be possible to solve these with git, by doing something like automatically running a `git stash --include-untracked` before an operation that can clobber untracked files.
- 5y ago
gldnspud 5y ago
While GitUp is a GUI app, and only available for macOS, I think it's worth noting that it has some great undo/redo capabilities built in. From what I understand, some of them were more feasible to develop because they implemented their own plumbing (GitUpKit), instead of relying on the official git plumbing. https://gitup.co/ https://gitup.co/
- dilap 5y ago
  GitUp is such a great app & fantastic UI design, but the author gave up on it at maybe 80% of functionality, and I think for that reason (among perhaps others), it never really caught on. (It's open source and there are still occasional commits, but it doesn't seem to be really actively worked.) Nevertheless my main daily driver, along w/ the command line. It's undo capabilities, best-in-class visualization of the timeline, and ability to easily visually edit, reworder, and squash commits remain amazing. (I was disappointed to see newer git clients like Submlime Merge did not take inspiration from GitUp.) Ultimately I think the future of VC will be something patch-based (pijul?) w/ a UI along the lines of GitUp.
  - jahnu 5y ago
    An ex-colleague of mine used to maintain a fork here. Maybe you could encourage him to continue :) https://github.com/douglashill/GitUp/releases https://github.com/douglashill/GitUp/releases
  - swisspol 5y ago
    Hey I didn't gave up on it at 80% functionality ;) It had 100% for my needs and it's been rock stable since then - I still use it daily! But yes, I wasn't really worth actively maintaining it as it was feature complete and I didn't intend to build a business out of it.
    - dilap 5y ago
      Yes, I also use it daily, so thanks for making an amazing tool! 100% vs 80% is of course going to be subjective, but the missing 20% in my opinion is built-in merging and a built-in repo browser. When I've tried to advocate GitUp to my coworkers, those are the two things that keep them going back to SourceTree or Fork. (Also, on our (admittedly, pretty large) repos, it's not quite rock-solid; staging can be unusably slow (requiring fallback to the command line), switching to the commit view from the map view can be slow, and making lots of changes to the working tree will crash GitUp.) Still, a brilliant piece of software, and I am suprised that (1) it didn't find a larger audience and (2) that it wasn't more influential on clients that came after, like Sublime Merge.
globular-toast 5y ago
> Here’s my theory: novice and intermediate users would significantly improve their understanding and efficacy with Git if they weren’t afraid of making mistakes. Agreed. When I was learning to climb the instructor told me I would never reach my full potential until after the first fall. You cannot work at your limit until you trust the rope. However, I think this is still avoiding the rope. Git is really simple and when you understand it it's hard to go wrong. I really think what git is missing is a better user interface. Magit is the only one I'm aware of.
- chalst 5y ago
  The easiest way to make mistakes cheap is to have your working directory on a filesystem with automatic snapshots, such as nilfs.
phonebucket 5y ago
git config --global alias.undo 'reset --soft HEAD~1' Not that I would include this in my own shell. To the authors two example uses: 1) Undoing an amended commit. But if you're comfortable amending a commit, can't you just amend your amended commit? 2) Accidentally commiting an incorrectly resolved merge conflict. Revert the change if you want to be non-destructive. Reset HEAD~1 otherwise.
- renewiltord 5y ago
  1. I believe it’s not that you want to amend it, but that you want to restore its pre-amended state. I would use the reflog to look that up and then reset to it but this makes that easy and hence, more accessible (which is good) 2. Yeah, but I think the UX improvement of a single command to say “Go back to where I was” is reasonable.
saiojd 5y ago
Great work. I wish usability/ergonomy was taken more seriously for popular tools that everyone uses (like git). Another stupid pain point with git is the inability to commit empty directories. I mean, come on.
- cerved 5y ago
  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
  - rileymat2 5y ago
    The use case it frustrates me in is when you want to work on the structure of the repository before you have all the code. For instance, it is nice to think about the repo holistically sometimes before I have say an actual unit test to put in the directory, it is nice to create that structure in the repo.
    - cerved 5y ago
      I see. But then why the record that structure in the index? Isn't it enough to have it remain in the working directory? Or if you need it in the index, just the canonical empty .gitignore?
  - saiojd 5y ago
    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 surprising, and 2) it offers no advantages to users, only disadvantages to some. Hence, it is unergonomic. My complaint was precisely that for extremely popular tools (such as git), it is worthwhile in general to sacrifice ease of implementation for ease of use, because the developper effort is amortized over the number of users.
windowojji 5y ago
`hg` literally already has `hg undo` as a command. It's good that `git` can have a similar tool
professoretc 5y ago
From the article: > How is it so easy to “lose” your data in a system that’s supposed to never lose your data? I think the author is mistaken; git isn't "a system that’s supposed to never lose your data". One of its features is the ability to "lose" data in a controlled way; i.e., to rewrite history. If you want a version control that is supposed to never lose data, use Fossil.
- gpanders 5y ago
  Even if you rewrite history, the data is not lost. The old commits are still in the reflog and can be recovered. It’s extremely difficult to lose anything in Git once it’s been committed. You’d have to do something pathological or intentional.
  - urxvtcd 5y ago
    It's also possible (if difficult) to recover files which have been git-added and not commited. The only files git can't recover are the ones that it hasn't registered in the first place.
- arxanas 5y ago
  This is a figurative use of the word "lose", hence the quotes. The beginner comes in with the impression that it's impossible to lose your data with Git, and then manages to "lose" it anyways. Whether it's really lost, or it's just that the user doesn't know how to get it back, isn't relevant from the novice's point of view.
pjettter 5y ago
Git should store the commands that "did" the operations on a repo. Git should never ever let you lose work. I should always be able to go "backward" and recover previous states. I guess that is what the "Git undo" proposal is about. I'm a very visual person so I tend to use Git Graph on VSCode. But I still get in trouble. Especially things like Cherry Picking, or reverting. Another thing that is not so easy is switching branches without having to do a commit. Stashing, yeah, but then figuring out whether stashes have been applied or not, diffing between branches, picking some changes from a diff. In the end I stick to some basic commands that don't get me in trouble so that I don't lose half a day to recover my work via Dropbox.
- prisonality 5y ago
  > Git should store the commands that "did" the operations on a repo. is `git reflog` not enough for your use case ?
  - pjettter 5y ago
    No, I mean more like an audit trail. Not like `blame` either. What I typed on the command line to get into a new state.
    - sixstringtheory 5y ago
      What about `history | grep “^git”? Edit to add: the downside is that it only works in the current terminal session. To workaround that for myself, I have a fish shell post exec function that records the last command run, plus a bunch of metadata, to a log file.
sedatk 5y ago
I think Mercurial is way ahead of Git on this department by having repositories immutable by default, so even undo actions would have their commit. You never find yourself in an unrecoverable situation. Advanced mutable features can only be accessed by making configuration changes, and are still safe to use because public changesets are differentiated from draft changesets, so, you can only make changes on your own work, not anything else. I mean, you can force it, but that comes with its warnings. Mercurial has no staging area, and that can be inconvenient for some scenarios; but I think no-staging model is easier to grasp for beginners. I especially think many beginners would assume that modifying a file after it's been added to staging area would update staging area automatically too. Mercurial has high-level, scenario-oriented distinct "undo" commands like "revert", "forget" and "backout" instead of overloading a single command ("reset") for everything. I still like `git reflog` though.
- umvi 5y ago
  Sounds like mercurial repos would have a lot of "noise" with that approach - commits for fixing other commits spamming everywhere
  - capitainenemo 5y ago
    https://www.mercurial-scm.org/doc/evolution/user-guide.html#changeset-obsolescence-under-the-hood https://www.mercurial-scm.org/doc/evolution/user-guide.html#... The key thing seems to be the immutable repo editing is hidden by default, but viewable with --hidden flag if you need it.
  - sedatk 5y ago
    Eh, some may call it noise, some may call it "thank God my work is saved!". That only applies to pushed changesets btw, may I remind you. You can obviously remove/restructure local commits as you like; you just need to enable certain extensions for mutability.
  - globular-toast 5y ago
    Git does too. It's garbage collected after 90 days or so. It doesn't amount to as much as you might think due to Git's data model.
thewebcount 5y ago
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 certainly one of the problems). Git is an incredibly user-hostile experience, and someone needs to fix or replace it. Can we just say it out loud and stop pretending that the problem is the literally thousands of users who have problems using it?
- sloucher 5y ago
  Last time I checked, 5 of the top 10 questions on StackOverflow were about Git...
  - adamrezich 5y ago
    still true! but that isn't a great metric necessarily, as #10 is "What is the “-->” operator in C/C++?" https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c-c https://stackoverflow.com/questions/1642028/what-is-the-oper... which is just a novelty rather than a common question
  - greenshackle2 5y ago
    Maybe because like 90% of devs use git; there's no language or framework that is used by so many.
- nexuist 5y ago
  The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either. In the rare case that someone hoses remote, yes you'll have to do some weird git-fu to get everyone working again, but it's really hard to hose remote if you stick to the pull -> commit -> push -> merge pattern, which is what 99% of users are doing anyways. I've used git for 9 years and I've never had to spend longer than an hour troubleshooting git based BS. And if you'll remember, 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.
renewiltord 5y ago
It is interesting. I’ve never had any trouble with git. I think the reason is that I learned it relatively early in my career and so I had the luxury of “What’s the right way to resolve this situation?”. I have never lost data despite using filter-branch, rebase, bad merges, bad rebases, bad branch deletes… Still, the UX sugar of undo sounds quite nice. I only worry about introducing something heavyweight into the thing. If I use branchless will it force others to use branchless too?
- arxanas 5y ago
  No, it doesn't force others to use branchless at all. The git undo data is stored in a separate database in your .git directory, so other people won't have access to it. (Of course, this means that they can't use git undo on your actions.)
gerbilly 5y ago
What makes git really complicated is that for every command you type, there are two things that may be affected: * the working copy * the graph And it gets better, if any file gets disconnected from the graph, it can be hard to locate. (Yes I know, it can be found in the reflog)
- rags2riches 5y ago
  Let's not forget about the index. Or is it called the staging area?
  - RichardCA 5y ago
    This conceptual overloading of language can be traced back to Linus' first commit. https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23... The original idea was "current directory cache" and that still pops up in the syntax. I always run "git diff --cached" as a last sanity check before a commit.
rexyg 5y ago
I can’t wait to start using this
caseydm 5y ago
This is a great idea. There are well-documented ways to undo things on stack overflow, but almost every way: 1. Has three competing ways available to complete the 'undo' 2. Every way has a scary caveat that the user must be aware of It would be awesome to simplify the process for new users.
whiddershins 5y ago
I don't understand. You can always restore any previous state using git, I used to do it from the command line. If I use github desktop I can roll back a commit whenever I like with a simple menu command. What am I missing here. I feel like I don't understand what the tool is doing.
- nerdponx 5y ago
  https://github.com/arxanas/git-branchless/wiki/Architecture#comparison-with-the-reflog https://github.com/arxanas/git-branchless/wiki/Architecture#...
- whalesalad 5y ago
  If you understand the fundamentals of a version control system I find git relatively intuitive to use. Sometimes I don’t know the exact cli syntax for a complicated procedure but that’s easy enough to figure out if you know the concepts. Most people fail to learn the concepts and then try to brute force everything.
  - cerved 5y ago
    Most people do not even seem the slightest inclined to bother. It's a sad attitude IMHO
- jonahx 5y ago
  The README for the parent repo (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless) answers these questions in detail. Short answer, recreating this tool's features in vanilla git requires using the reflog, which isn't user-friendly: > Why not git reflog? > git reflog is a tool to view the previous position of a single reference (like HEAD), which can be used to undo operations. But since it only tracks the position of a single reference, complicated operations like rebases can be tedious to reverse-engineer. git undo operates at a higher level of abstraction: the entire state of your repository.
rglover 5y ago
Calling attention to this which has an undo command and has been very helpful for Git tasks: https://github.com/tj/git-extras https://github.com/tj/git-extras
quickthrower2 5y ago
Nice, I can evolve from https://xkcd.com/1597/ https://xkcd.com/1597/
alkonaut 5y ago
I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the elegance and consistency of an early php draft that went through a document shredder. Git has a nice elegant layer underneath though. The DAG of commits is a very nice model, covered in a layer of terrible commands, and a few rather unnatural abstractions like the staging area. I think to effectively use it you need to work with your brain squarely in that lower layer. Trying to think in terms of sequences of commands rather than a tree of commits and references is hopeless. The fact that the UX concepts (commands, working copy, reflog staging area, …) and the underlying model (graph) are difficult to reconcile is git’s biggest weakness. The difficulty with which is models some of the most common use cases (centralized, often including a few large binary files) is another.
- yarg 5y ago
  There's a limitation to the DAG model that has bothered me for a long time. I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch. I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances. (And I know this would create some new fun and games from a conflicts perspective, but I think it'd be worth it for any use case that involves long term maintenance of different releases of the same piece of software.)
  - leafmeal 5y ago
    So like a branch that automatically rebases on another branch? I think the issue with this is the inevitable conflicts and race-conditions. While nice in theory, often you need manual control to sort things out.
    - yarg 5y ago
      Not quite - branches get ancestors. A new repository starts with an empty branch. A DAG gets layered on top. I mentioned conflicts, but can you explain where race conditions would arise?
kbd 5y ago
I'll often launch lazygit just to use its undo feature since that's easier than navigating the reflog. Happy to see a standalone utility.
deknos 5y ago
i wish the branchless tools would be incorporated in standard git. :|
chuckdries 5y ago
gitkraken also has an undo button
29athrowaway 5y ago
There is a large graveyard of "simple git tools", many of them portray themselves as happy GUIs that prevent you from learning git... None of them works. At some point you will be told to fix the problem by hand.
- rjmunro 5y ago
  This. The tools that do work are ones that add a simple extra function (git absorb is really cool, for example), or GUIs that help you visualise the repository and give you buttons that have the same names as the command lines that they replicate. Tools that try to make things "easier" are just confusing for people who know git, and prevent you ever learning git for real. When I first tried it, github desktop was firmly in this category. We need to get git itself to adopt some changes - git switch is a good start, replacing checkout's branch switching features. I think that every time I do git checkout branch I should get a reminder to use git switch instead.
  - arthurcolle 5y ago
    git absorb looks sick, thanks for sharing! Any other dark magic you want to share?
jldugger 5y ago
`git-undo` has been part of git-extras[1] for a while. It doesn't use fancy git magic, so maybe this is better. [1]: https://github.com/tj/git-extras https://github.com/tj/git-extras
- skrebbel 5y ago
  It only removes the last commit. It's terribly named IMO, actually, cause I think that's seldomly the kind of thing you get into "omg I messed up how do I undo" panic for. The undo described here is much more powerful and much closer to what people expect from the word "undo" from its functionality in other tools.
jonathanberger 5y ago
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 don't there's often at least some theory about what is going on (network effects, business partnership, government regulation, etc.) that I don't have with these two products.
- leotaku 5y ago
  I would guess that network effects and the amount of quality tools built on top of Git are the main reason for its prevalence. Fossil and Darcs sure look nice, but having to self-host my repositories or use a smaller company that could go under at any minute? Having to use barely-maintained plugins for my editor, CI, CD, etc.? And most importantly, having to explain a completely new set of tools to anyone who wants to work on my projects? In my opinion, it just isn't worth it.
- MetaWhirledPeas 5y ago
  It has remained popular because it feels like the correct approach in almost every situation, despite having a difficult, obtuse UI. After spending years with Microsoft's centralized version control and then switching to Git it's like a breath of fresh air. Granted, I almost never use the Git command line and always favor a 3rd party GUI. For users who are a tad confused I think this is the right approach. And to me that's what makes Git a winner: the core software is powerful enough to do everything that needs to be done, and you can pick whatever UI you're comfortable with. No one is forcing you to use Git's built-in UI. That said I think even the high-level Git concepts have naming that confuses new users. "Pull request" annoyed me for a long time. Yes I technically understood why they chose that term, but practically speaking it just seemed pointlessly misleading.
- secondcoming 5y ago
  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++.
cratermoon 5y ago
It's almost impossible to really lose anything once it's committed to git. Just look at the efforts it takes to really remove accidentally committed secrets. The hard part is understanding how to get a reference to the thing you want to get back, how to restore it to its proper place in the history, or at least to a reasonable place, and how, if it's been pushed to a shared repo, for other developers to get their local clone properly sync'd up without their local work getting shoved off into some hard-to-reach reference.
vzaliva 5y ago
May I have it in Magit, please?
- snackematician 5y ago
  Magit's wip-mode seems similar in some respects: https://magit.vc/manual/magit/Wip-Modes.html https://magit.vc/manual/magit/Wip-Modes.html I haven't tried it, but have been meaning to look into it. Would be curious to hear experiences of anyone who's tried it, and how it compares to the OP.
vgaldikas 5y ago
Shouldn't the article be called "We can undo better" :D
workethics 5y ago
I feel like an outcast after reading all the comments here. I've never really had issues using git. I didn't realize so many people had trouble with it.
- ggregoire 5y ago
  That's what I was thinking. I barely understand how git works but I've never had issues neither. Could be because people don't have a good workflow. Mine is as simple as: - git pull -r (to pull & automatically rebase commits from the common branch) - git checkout -b (to create my own feature/debug branch from the common branch) - git add -A/commit -m/push (to add, commit and push… I usually let my IDE handle that part) - git rebase (to rebase commits from the common branch) - git reset (to squash all the "WIP" and "fix" commits on my feature/debug branch. I then do 1 or 2 clean commits and push -f) - finally I do a merge request, or directly git cherry-pick the commits to the original branch if nobody else works on the project I've been doing this for years and it just works.
- kingaillas 5y ago
  Meanwhile, I refer to Git Flight Rules (https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules) on a weekly basis. Especially the branches section - somehow I'm checking in or pulling from the wrong branch, or branching from the wrong parent, and cleaning up is so tedious/annoying. I'm gonna check out this "git undo" command in the article.
MehdiHK 5y ago
Git Tower GUI app has undo feature too, which is very handy. They announced it in this post: https://www.git-tower.com/blog/how-we-built-undo/ https://www.git-tower.com/blog/how-we-built-undo/
chagaif 5y ago
I'm still scared of using got undo
Vaslo 5y ago
I used GIT recently for tracking an SSIS package and despite many commits I still have no idea whether I should use a rebase or a reset or a hard reset. Reading the manual does not help. I just simply want to undo a mistake. Glad I am not the only one who feels dumb about this.
robin_m 5y ago
Quick tips for people that find git confusing: - Use a recent version of git. The error messages have improved a lot, have been localized (unless you do `LANG=C git …` to be able to search it on internet), the UI has improved, `git status` is more helpfull, … - Create an alias for `git log --graph --decorate --oneline --all` or something fancier with `--format`. `--graph` should help you a lot to visualise stuff. - Don't use `git reflog` but `git log --graph --reflog`, it's much easier to visualize. - Never use `git checkout`, but `git switch` and "git restore` that were introduced in git 2.15 IIRC. They are much less confusing and error prone. - `--patches` (`-p` for short) can be used with `add`, `restore`, `reset`, `log`. It helps a lot with commit hygiene. - Most complex rebase are easier to do with `--interactive` (`-i`). - Activate `rerere` in your git config (it will reduce conflict merges during rebases).
neycoda 5y ago
git --stop --being --stupid
neycoda 5y ago
This is completely unnecessary. I've been able to fix every mistake I've seen in the last 5 years with variations of git diff, git branch, git merge, git reset and git rebase and their options, and I've seen some horrific doozies from newbs and pros.
0xbadcafebee 5y ago
Git is just a horrible user interface, period. Linus named it "git" because it's clearly kind of stupid. But it works for many people. Other version control systems are much better for beginners (especially centralized ones). But mainly they are easier because they're designed to be user friendly. But nobody's going to solve the major problems of Git any time soon, because you can eventually get Git to work. This is a persistent problem I see all over the tech landscape. We live with crappy solutions because trying to make a better one is way more work than just dealing with the bad one. Progress isn't impossible, it's just tedious.
ori_b 5y ago
This sounds like an idea that I can implement in 9front's native git reimplementation pretty easily. May be my next weekend project.
jacobsenscott 5y ago
Git is hard to use mostly due to "clean commit history" cargo culting. The commands that cause the most trouble are the command that re-write history, and there really is never a good reason to use them beyond "I want my commit history to look like a line".
- cerved 5y ago
  Tbf, rewriting local history makes a ton of sense but with great power comes great responsibility
Milkman128 5y ago
Team explorer saves my days. Playing with command prompts for simple tasks is never ideal
bedobi 5y ago
A huge reason why undoing things in Git get needlessly confusing is using merge commits in the first place. I've always advocated ONLY squash commits to master. It makes things much, much easier to understand, and much, much easier to undo things with equally easy to understand regular git reverts.
radres 5y ago
I can't believe how so many devs are hating git. It is one of the best tools in software engineering.
shruti346 5y ago
I was thinking same yesterday coz I did a wrong commit
alxndrr 5y ago
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/ https://www.git-tower.com/blog/how-we-built-undo/
- arxanas 5y ago
  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 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...)
johnisgood 5y ago
So many people that have issues with git, yet it still is quite popular... everywhere. I wonder if they would do any better with another VCS. I do look forward to pijul.

762 points by arxanas 5y ago

Simplicitas 5y ago

This is an awesome idea. Can't wait to hear the objections from the purists.

idoubtit 5y ago
I've watched the first case: amend a commit then undo. And I believe it shows serious shortcomings : - The interactive interface of `git undo` is probably too hard for beginners. Designing simple interfaces is hard, and you can't pplease everyone. - It seems `git undo` simply does a `git reset--hard` toward a designed commit. The user probably expected to return to the state before the last git action. Instead `git undo` reverted the amend, but also reset the index and remove the local changes. At this point, the beginner could scream "Undo lost my changes! I just wanted a second commit instead of an amend." Undoing could mean `git reset --hard {hash}`, but in many cases `--hard` would have unwanted effect and the default `--mixed` would be more suitable. But even in this case, it's not a full undo, since the index is not preserved: you don't end up in the same state as before the `commit --amend`.
- arxanas 5y ago
  There is a design to address undoing changes to the index: https://github.com/arxanas/git-branchless/issues/10 https://github.com/arxanas/git-branchless/issues/10 It runs a `git checkout`, not a `git reset --hard`, so it will stop you if there are incompatible changes. Of course, if `git undo` can be made to lose your staged or unstaged work, then that's a bug. Fortunately, you can undo the result of any `git undo` with another `git undo` that goes one more step back in time.
- spicybright 5y ago
  Why is it so hard to implement a git undo? You have a previous state, and a current state. Just roll it back.
RichardCA 5y ago
The purist will say: You are always free to write your own porcelain.

girishso 5y ago

This seems like a very good idea. Only if we can scroll through the commit hashes and see the preview of commit with help of fzf or something similar, it will be totally awesome.

max_hammer 5y ago
I use maggit and can scroll commit log using `ll` You can also try `lazygit` it's a TUI written in Go
- zhynn 5y ago
  I have been using lazygit for about six months, and I love it.
- girishso 5y ago
  lazygit offers undo like OP's command? I don't think so. What I meant was Git undo displays a list of commits, I would like to see those commit's contents as well, we can do it with fzf.
arxanas 5y ago
I would like to add fzf-style interfaces to checking out more things. Hopefully, they could index both the commit message and the commit contents when searching.
- girishso 5y ago
  Totally possible, I've following helper in my .zshrc # fshow - git commit browser fshow() { git log --graph --color=always HEAD \ --format="%C(auto)%h%d %s %C(blue)(%aN) %C(black)%C(bold)%cr" "$@" | fzf --ansi --no-sort --reverse --tiebreak=index --bind=ctrl-s:toggle-sort \ --bind "j:down,k:up,q:abort,ctrl-m:execute: (grep -o '[a-f0-9]\{7\}' | head -1 | xargs -I % sh -c 'git show --color=always % | less -R') << 'FZF-EOF' {} FZF-EOF" }

sombremesa 5y ago

> Here’s my theory: novice and intermediate users would significantly improve their understanding and efficacy with Git if they weren’t afraid of making mistakes. Here's something that happens when people are encouraged to make more mistakes: they make more mistakes. The piece where people are encouraged to learn from these mistakes is missing from the author's equation. Without that, this tool becomes a crutch at best, and a disaster waiting to happen at worst. Can we do better? *Edit*: Let me answer my own question. We can do better - for example - simply by adding the Git commands this program would run, aside from the human readable explanation. Not sure what people replying to this comment were aiming for, since they clearly did not offer up a single suggestion. Let me go a bit further and add that self-righteous soapboxes are NOT a good thing, and as it stands none of the replies to this comment were relevant. I was hoping to spark a discussion of what else could be done to improve the experience, but I could have worded my comment better. On the other hand, you can do better.

_jal 5y ago
Perhaps it should have been stated outright, but the operative theory appears to be that if mistakes cost less, making more of them becomes the learning exercise.
- deleted 5y ago
  [deleted]
yoz-y 5y ago
I wouldn't be so harsh. I don't know a single program that was made worse by adding undo. Imagine a painting program without it. (I'm sure there are some artistic programs that do that but those would be mostly toys) Trying to learn from mistakes that can be solved by an undo on local repository are mostly in the realm of "be more careful", which is an impossible requirement to achieve in general.
- shadowgovt 5y ago
  The cost of adding undo is usually the cost itself (i.e. every operation the program can do must now be considered for its reversibility). Not every program justifies that cost, but I have also never seen a program that was made worse by adding it.

max_hammer 5y ago

How hard is `git reflog` `git reset --hard <SHA of commit you want >` Or if you just want to move back 1 commit `git reset HEAD@{1}`

leifg 5y ago
git reflog is hard enough so that I (a software engineer for 12 years and a git user for 10+ years) have to look up its syntax every time I need it.
- SamBam 5y ago
  Can you explain what's tricky about it? For me, I just had to remember that "reflog" was the name for "history." Once I did that, everything else is just regular git commands. Check out a "commit." Revert to a "commit."
- amelius 5y ago
  I think this is the problem with any command which you only need once in a blue moon. I always forget how to set up networking, because I don't do it often enough.
- juped 5y ago
  Weird, it has no syntax...
  - thewebcount 5y ago
    I'm not sure what you mean. Typing "git help reflog" brings up a man page that lists commands like "show", "expire", "delete", etc., each with additional options.
    - stevenhuang 5y ago
      Because the most common usage is to run it with no arguments.
- mattkrause 5y ago

eric4smith 5y ago

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 implications? We don't really know. I feel stupid. But hey, at least I'm honest.

sebmellen 5y ago
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.
- zibzab 5y ago
  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
  - disgruntledphd2 5y ago
    GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.
    - zabzonk 5y ago
      Bitbucket used to provide free (and pretty good) Mercurial hosting.
      - oblio 5y ago
        Bitbucket had a much crappier UI.

voiper1 5y ago

Reference to a helpful wizard for fixing your git mistake: http://sethrobertson.github.io/GitFixUm/fixup.html http://sethrobertson.github.io/GitFixUm/fixup.html

Egoist 5y ago
Wow, probably one of the best guides i have seen for git. Wish i knew this existed when i was a beginner
swyx 5y ago
i can’t believe nobody has mentioned https://ohshitgit.com https://ohshitgit.com so here i am to mention it

amelius 5y ago

Would this work on a pull from a remote? Or how about after pushing to a remote?

arxanas 5y ago
Pull from a remote: yes, it will rewind the local references to their old positions. Push: sadly, no.

zach_garwood 5y ago

This seems like putting a training wheel on a training wheel. git is already the easiest to understand of any VCS that I've used, and it's somewhat hard to do something in git that can't be reversed. As the articles states, it's unlikely you'll ever lose your changes. Further, this doesn't seem to be that different of a concept from git reset, so why not learn reset instead of yet another command?

simias 5y ago
Hard disagree, git's docs and UI have improved over the years but every time I have to teach it to a beginner I realize how arcane and scary it is, especially when compared to old school centralized VCSs like subversion. Not that I'd trade git for subversion mind you, in the hands of a trained individual git is a godsend, but the training part can be arduous. Even among DVCSs I'd argue that mercurial for instance is vastly easier to pick up.
- zach_garwood 5y ago
  If it's an issue of having to read the docs or the man, well I've been at work like this for a little over a decade and I still have to pull up a reference when I want to do something nontrivial in, not only git, but pretty much every cli tool I use on a regular basis. Cli tools, frameworks, libraries, languages... I have to pull up a reference for everything I do as a programmer, so it's hard for me to muster up the indignity for having to look up how git works. If it's a matter of understanding the flow of the tool, then I will have to concede that mercurial probably is easier to understand for the beginner.
  - rileymat2 5y ago
    `git add <file>` Wait, how do I remove it from staging? It seems there should be some symmetric operation, `git remove <file>` or something. Maybe git rm `<file>`, whoa don't do that. No, it is `git reset HEAD -- <file>`. There is no mental symmetry. Or why use add at all? What am I adding it to? It is so generic, why not `git stage file` and `git unstage file`? I agree that you need to read and learn tools, but there is a lack of consistency and symmetry in many of the commands which make it harder.

float4 5y ago

> novice users are terrified of it. When they make a mistake, many would rather delete and re-clone the repository than try to fix it In my experience most beginners use a GUI like Atlassian Sourcetree or the Github desktop client. It's a lot harder to make mistakes using the GUI in my experience. I still really like this idea though; eventually a subset of the beginners wants to learn the git cli and that sure seems scary at first.

arxanas 5y ago
GUI tools are a great step forward in my opinion, not because the GUIs are necessary, but because the Git command-line interface is really terrible. I would like to see a GUI adopt these concepts. There's no reason why we should limit the commit graph display to only the current time, when we have enough information to scroll through its past states as well.
lukeinator42 5y ago
I really love the Jetbrains GUI built into their IDEs for this.
Osiris 5y ago
For JetBrains users, there is a built-in Git GUI as well. It's not as easy to use as SourceTree, but since there's no SourceTree for Linux, it works well enough.
jahnu 5y ago
Can I give a shout out to Fork here for being another great GUI for git. I'm not affiliated with them in any way. Just a happy customer. https://git-fork.com/ https://git-fork.com/
- dewey 5y ago
  Agreed, another happy Fork user here. I switched from Tower as it just got more and more expensive and added features I don't need.
contriban 5y ago

deleted 5y ago

[deleted]

Jakobeha 5y ago

Any other recommendations for CLI tools? I've gotten kind of familiar with the Git CLI. But it took a lot of wasted hours and headaches to do so, and even now it takes headaches and extra time / effort to do certain things like rewrite history and "good" commits. I still prefer CLI to GUI but I wish it was more intuitive.

arxanas 5y ago
You should check out the rest of the git-branchless suite mentioned in the article: https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless. `git restack` is really useful for some of the rewrite cases. There are some other improvements to rewriting in the devel branch.
jph 5y ago
Git Alias has many: https://github.com/gitalias/gitalias https://github.com/gitalias/gitalias
jgilias 5y ago
There's tig: https://jonas.github.io/tig/ https://jonas.github.io/tig/ It doesn't have too many features, but the main thing it aims for - a better repo browser, it does really well in my opinion.
- qq4 5y ago
  I can second tig, it really helps me parse the repo.
sensanaty 5y ago
I like forgit a lot, been using it for a while https://github.com/wfxr/forgit https://github.com/wfxr/forgit

optymizer 5y ago

This is an excellent idea and I'm glad it's making its way into the open source community. My company has an equivalent to 'git undo' that basically undoes anything you just did to your local repo. It's just so freeing. Sometimes you need that Ctrl+Z so you can undo and redo things correctly. It gets your mind back to whatever you were doing before without needing to debug wtf just happened.

noxer 5y ago

obligatory mention of fossil-scm.org just in case someone don't know yet and would like a version control system++ that actually works for/with you.

OhNoMyqueen 5y ago

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.

juped 5y ago
Also from deleting their whole checkout.
nsomaru 5y ago
Am I doing things wrong if I have never used these commands?
- jdauriemma 5y ago
  Try not to think of it in terms of right and wrong. `git clean` is useful, though not "can't-live-without-it" useful. I couldn't imagine my workflow without `git reset`, though, and I recommend checking it out!
- jonahx 5y ago
  Probably not using git ideally. Do you clean your history after working on a feature?
- rjmunro 5y ago
  No, IMHO you are doing things right. I virtually never use those commands, I've been using git for well over 10 years, and have totally got used to all it's quirks.
anamexis 5y ago
I agree, these are the only times I've irreversibly gotten myself into trouble. I think it would be possible to solve these with git, by doing something like automatically running a `git stash --include-untracked` before an operation that can clobber untracked files.
5y ago

gldnspud 5y ago

While GitUp is a GUI app, and only available for macOS, I think it's worth noting that it has some great undo/redo capabilities built in. From what I understand, some of them were more feasible to develop because they implemented their own plumbing (GitUpKit), instead of relying on the official git plumbing. https://gitup.co/ https://gitup.co/

dilap 5y ago
GitUp is such a great app & fantastic UI design, but the author gave up on it at maybe 80% of functionality, and I think for that reason (among perhaps others), it never really caught on. (It's open source and there are still occasional commits, but it doesn't seem to be really actively worked.) Nevertheless my main daily driver, along w/ the command line. It's undo capabilities, best-in-class visualization of the timeline, and ability to easily visually edit, reworder, and squash commits remain amazing. (I was disappointed to see newer git clients like Submlime Merge did not take inspiration from GitUp.) Ultimately I think the future of VC will be something patch-based (pijul?) w/ a UI along the lines of GitUp.
- jahnu 5y ago
  An ex-colleague of mine used to maintain a fork here. Maybe you could encourage him to continue :) https://github.com/douglashill/GitUp/releases https://github.com/douglashill/GitUp/releases
- swisspol 5y ago
  Hey I didn't gave up on it at 80% functionality ;) It had 100% for my needs and it's been rock stable since then - I still use it daily! But yes, I wasn't really worth actively maintaining it as it was feature complete and I didn't intend to build a business out of it.
  - dilap 5y ago
    Yes, I also use it daily, so thanks for making an amazing tool! 100% vs 80% is of course going to be subjective, but the missing 20% in my opinion is built-in merging and a built-in repo browser. When I've tried to advocate GitUp to my coworkers, those are the two things that keep them going back to SourceTree or Fork. (Also, on our (admittedly, pretty large) repos, it's not quite rock-solid; staging can be unusably slow (requiring fallback to the command line), switching to the commit view from the map view can be slow, and making lots of changes to the working tree will crash GitUp.) Still, a brilliant piece of software, and I am suprised that (1) it didn't find a larger audience and (2) that it wasn't more influential on clients that came after, like Sublime Merge.

globular-toast 5y ago

> Here’s my theory: novice and intermediate users would significantly improve their understanding and efficacy with Git if they weren’t afraid of making mistakes. Agreed. When I was learning to climb the instructor told me I would never reach my full potential until after the first fall. You cannot work at your limit until you trust the rope. However, I think this is still avoiding the rope. Git is really simple and when you understand it it's hard to go wrong. I really think what git is missing is a better user interface. Magit is the only one I'm aware of.

chalst 5y ago
The easiest way to make mistakes cheap is to have your working directory on a filesystem with automatic snapshots, such as nilfs.

phonebucket 5y ago

git config --global alias.undo 'reset --soft HEAD~1' Not that I would include this in my own shell. To the authors two example uses: 1) Undoing an amended commit. But if you're comfortable amending a commit, can't you just amend your amended commit? 2) Accidentally commiting an incorrectly resolved merge conflict. Revert the change if you want to be non-destructive. Reset HEAD~1 otherwise.

renewiltord 5y ago
1. I believe it’s not that you want to amend it, but that you want to restore its pre-amended state. I would use the reflog to look that up and then reset to it but this makes that easy and hence, more accessible (which is good) 2. Yeah, but I think the UX improvement of a single command to say “Go back to where I was” is reasonable.

saiojd 5y ago

Great work. I wish usability/ergonomy was taken more seriously for popular tools that everyone uses (like git). Another stupid pain point with git is the inability to commit empty directories. I mean, come on.

cerved 5y ago
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
- rileymat2 5y ago
  The use case it frustrates me in is when you want to work on the structure of the repository before you have all the code. For instance, it is nice to think about the repo holistically sometimes before I have say an actual unit test to put in the directory, it is nice to create that structure in the repo.
  - cerved 5y ago
    I see. But then why the record that structure in the index? Isn't it enough to have it remain in the working directory? Or if you need it in the index, just the canonical empty .gitignore?
- saiojd 5y ago
  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 surprising, and 2) it offers no advantages to users, only disadvantages to some. Hence, it is unergonomic. My complaint was precisely that for extremely popular tools (such as git), it is worthwhile in general to sacrifice ease of implementation for ease of use, because the developper effort is amortized over the number of users.

windowojji 5y ago

`hg` literally already has `hg undo` as a command. It's good that `git` can have a similar tool

professoretc 5y ago

From the article: > How is it so easy to “lose” your data in a system that’s supposed to never lose your data? I think the author is mistaken; git isn't "a system that’s supposed to never lose your data". One of its features is the ability to "lose" data in a controlled way; i.e., to rewrite history. If you want a version control that is supposed to never lose data, use Fossil.

gpanders 5y ago
Even if you rewrite history, the data is not lost. The old commits are still in the reflog and can be recovered. It’s extremely difficult to lose anything in Git once it’s been committed. You’d have to do something pathological or intentional.
- urxvtcd 5y ago
  It's also possible (if difficult) to recover files which have been git-added and not commited. The only files git can't recover are the ones that it hasn't registered in the first place.
arxanas 5y ago
This is a figurative use of the word "lose", hence the quotes. The beginner comes in with the impression that it's impossible to lose your data with Git, and then manages to "lose" it anyways. Whether it's really lost, or it's just that the user doesn't know how to get it back, isn't relevant from the novice's point of view.

pjettter 5y ago

Git should store the commands that "did" the operations on a repo. Git should never ever let you lose work. I should always be able to go "backward" and recover previous states. I guess that is what the "Git undo" proposal is about. I'm a very visual person so I tend to use Git Graph on VSCode. But I still get in trouble. Especially things like Cherry Picking, or reverting. Another thing that is not so easy is switching branches without having to do a commit. Stashing, yeah, but then figuring out whether stashes have been applied or not, diffing between branches, picking some changes from a diff. In the end I stick to some basic commands that don't get me in trouble so that I don't lose half a day to recover my work via Dropbox.

prisonality 5y ago
> Git should store the commands that "did" the operations on a repo. is `git reflog` not enough for your use case ?
- pjettter 5y ago
  No, I mean more like an audit trail. Not like `blame` either. What I typed on the command line to get into a new state.
  - sixstringtheory 5y ago
    What about `history | grep “^git”? Edit to add: the downside is that it only works in the current terminal session. To workaround that for myself, I have a fish shell post exec function that records the last command run, plus a bunch of metadata, to a log file.

sedatk 5y ago

I think Mercurial is way ahead of Git on this department by having repositories immutable by default, so even undo actions would have their commit. You never find yourself in an unrecoverable situation. Advanced mutable features can only be accessed by making configuration changes, and are still safe to use because public changesets are differentiated from draft changesets, so, you can only make changes on your own work, not anything else. I mean, you can force it, but that comes with its warnings. Mercurial has no staging area, and that can be inconvenient for some scenarios; but I think no-staging model is easier to grasp for beginners. I especially think many beginners would assume that modifying a file after it's been added to staging area would update staging area automatically too. Mercurial has high-level, scenario-oriented distinct "undo" commands like "revert", "forget" and "backout" instead of overloading a single command ("reset") for everything. I still like `git reflog` though.

umvi 5y ago
Sounds like mercurial repos would have a lot of "noise" with that approach - commits for fixing other commits spamming everywhere
- capitainenemo 5y ago
  https://www.mercurial-scm.org/doc/evolution/user-guide.html#changeset-obsolescence-under-the-hood https://www.mercurial-scm.org/doc/evolution/user-guide.html#... The key thing seems to be the immutable repo editing is hidden by default, but viewable with --hidden flag if you need it.
- sedatk 5y ago
  Eh, some may call it noise, some may call it "thank God my work is saved!". That only applies to pushed changesets btw, may I remind you. You can obviously remove/restructure local commits as you like; you just need to enable certain extensions for mutability.
- globular-toast 5y ago
  Git does too. It's garbage collected after 90 days or so. It doesn't amount to as much as you might think due to Git's data model.

thewebcount 5y ago

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 certainly one of the problems). Git is an incredibly user-hostile experience, and someone needs to fix or replace it. Can we just say it out loud and stop pretending that the problem is the literally thousands of users who have problems using it?

sloucher 5y ago
Last time I checked, 5 of the top 10 questions on StackOverflow were about Git...
- adamrezich 5y ago
  still true! but that isn't a great metric necessarily, as #10 is "What is the “-->” operator in C/C++?" https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c-c https://stackoverflow.com/questions/1642028/what-is-the-oper... which is just a novelty rather than a common question
- greenshackle2 5y ago
  Maybe because like 90% of devs use git; there's no language or framework that is used by so many.
nexuist 5y ago
The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either. In the rare case that someone hoses remote, yes you'll have to do some weird git-fu to get everyone working again, but it's really hard to hose remote if you stick to the pull -> commit -> push -> merge pattern, which is what 99% of users are doing anyways. I've used git for 9 years and I've never had to spend longer than an hour troubleshooting git based BS. And if you'll remember, 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.

renewiltord 5y ago

It is interesting. I’ve never had any trouble with git. I think the reason is that I learned it relatively early in my career and so I had the luxury of “What’s the right way to resolve this situation?”. I have never lost data despite using filter-branch, rebase, bad merges, bad rebases, bad branch deletes… Still, the UX sugar of undo sounds quite nice. I only worry about introducing something heavyweight into the thing. If I use branchless will it force others to use branchless too?

arxanas 5y ago
No, it doesn't force others to use branchless at all. The git undo data is stored in a separate database in your .git directory, so other people won't have access to it. (Of course, this means that they can't use git undo on your actions.)

gerbilly 5y ago

What makes git really complicated is that for every command you type, there are two things that may be affected: * the working copy * the graph And it gets better, if any file gets disconnected from the graph, it can be hard to locate. (Yes I know, it can be found in the reflog)

rags2riches 5y ago
Let's not forget about the index. Or is it called the staging area?
- RichardCA 5y ago
  This conceptual overloading of language can be traced back to Linus' first commit. https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23... The original idea was "current directory cache" and that still pops up in the syntax. I always run "git diff --cached" as a last sanity check before a commit.

rexyg 5y ago

I can’t wait to start using this

caseydm 5y ago

This is a great idea. There are well-documented ways to undo things on stack overflow, but almost every way: 1. Has three competing ways available to complete the 'undo' 2. Every way has a scary caveat that the user must be aware of It would be awesome to simplify the process for new users.

whiddershins 5y ago

I don't understand. You can always restore any previous state using git, I used to do it from the command line. If I use github desktop I can roll back a commit whenever I like with a simple menu command. What am I missing here. I feel like I don't understand what the tool is doing.

nerdponx 5y ago
https://github.com/arxanas/git-branchless/wiki/Architecture#comparison-with-the-reflog https://github.com/arxanas/git-branchless/wiki/Architecture#...
whalesalad 5y ago
If you understand the fundamentals of a version control system I find git relatively intuitive to use. Sometimes I don’t know the exact cli syntax for a complicated procedure but that’s easy enough to figure out if you know the concepts. Most people fail to learn the concepts and then try to brute force everything.
- cerved 5y ago
  Most people do not even seem the slightest inclined to bother. It's a sad attitude IMHO
jonahx 5y ago
The README for the parent repo (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless) answers these questions in detail. Short answer, recreating this tool's features in vanilla git requires using the reflog, which isn't user-friendly: > Why not git reflog? > git reflog is a tool to view the previous position of a single reference (like HEAD), which can be used to undo operations. But since it only tracks the position of a single reference, complicated operations like rebases can be tedious to reverse-engineer. git undo operates at a higher level of abstraction: the entire state of your repository.

rglover 5y ago

Calling attention to this which has an undo command and has been very helpful for Git tasks: https://github.com/tj/git-extras https://github.com/tj/git-extras

quickthrower2 5y ago

Nice, I can evolve from https://xkcd.com/1597/ https://xkcd.com/1597/

alkonaut 5y ago

I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the elegance and consistency of an early php draft that went through a document shredder. Git has a nice elegant layer underneath though. The DAG of commits is a very nice model, covered in a layer of terrible commands, and a few rather unnatural abstractions like the staging area. I think to effectively use it you need to work with your brain squarely in that lower layer. Trying to think in terms of sequences of commands rather than a tree of commits and references is hopeless. The fact that the UX concepts (commands, working copy, reflog staging area, …) and the underlying model (graph) are difficult to reconcile is git’s biggest weakness. The difficulty with which is models some of the most common use cases (centralized, often including a few large binary files) is another.

yarg 5y ago
There's a limitation to the DAG model that has bothered me for a long time. I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch. I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances. (And I know this would create some new fun and games from a conflicts perspective, but I think it'd be worth it for any use case that involves long term maintenance of different releases of the same piece of software.)
- leafmeal 5y ago
  So like a branch that automatically rebases on another branch? I think the issue with this is the inevitable conflicts and race-conditions. While nice in theory, often you need manual control to sort things out.
  - yarg 5y ago
    Not quite - branches get ancestors. A new repository starts with an empty branch. A DAG gets layered on top. I mentioned conflicts, but can you explain where race conditions would arise?

kbd 5y ago

I'll often launch lazygit just to use its undo feature since that's easier than navigating the reflog. Happy to see a standalone utility.

deknos 5y ago

i wish the branchless tools would be incorporated in standard git. :|

chuckdries 5y ago

gitkraken also has an undo button

29athrowaway 5y ago

There is a large graveyard of "simple git tools", many of them portray themselves as happy GUIs that prevent you from learning git... None of them works. At some point you will be told to fix the problem by hand.

rjmunro 5y ago
This. The tools that do work are ones that add a simple extra function (git absorb is really cool, for example), or GUIs that help you visualise the repository and give you buttons that have the same names as the command lines that they replicate. Tools that try to make things "easier" are just confusing for people who know git, and prevent you ever learning git for real. When I first tried it, github desktop was firmly in this category. We need to get git itself to adopt some changes - git switch is a good start, replacing checkout's branch switching features. I think that every time I do git checkout branch I should get a reminder to use git switch instead.
- arthurcolle 5y ago
  git absorb looks sick, thanks for sharing! Any other dark magic you want to share?

jldugger 5y ago

`git-undo` has been part of git-extras[1] for a while. It doesn't use fancy git magic, so maybe this is better. [1]: https://github.com/tj/git-extras https://github.com/tj/git-extras

skrebbel 5y ago
It only removes the last commit. It's terribly named IMO, actually, cause I think that's seldomly the kind of thing you get into "omg I messed up how do I undo" panic for. The undo described here is much more powerful and much closer to what people expect from the word "undo" from its functionality in other tools.

jonathanberger 5y ago

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 don't there's often at least some theory about what is going on (network effects, business partnership, government regulation, etc.) that I don't have with these two products.

leotaku 5y ago
I would guess that network effects and the amount of quality tools built on top of Git are the main reason for its prevalence. Fossil and Darcs sure look nice, but having to self-host my repositories or use a smaller company that could go under at any minute? Having to use barely-maintained plugins for my editor, CI, CD, etc.? And most importantly, having to explain a completely new set of tools to anyone who wants to work on my projects? In my opinion, it just isn't worth it.
MetaWhirledPeas 5y ago
It has remained popular because it feels like the correct approach in almost every situation, despite having a difficult, obtuse UI. After spending years with Microsoft's centralized version control and then switching to Git it's like a breath of fresh air. Granted, I almost never use the Git command line and always favor a 3rd party GUI. For users who are a tad confused I think this is the right approach. And to me that's what makes Git a winner: the core software is powerful enough to do everything that needs to be done, and you can pick whatever UI you're comfortable with. No one is forcing you to use Git's built-in UI. That said I think even the high-level Git concepts have naming that confuses new users. "Pull request" annoyed me for a long time. Yes I technically understood why they chose that term, but practically speaking it just seemed pointlessly misleading.
secondcoming 5y ago
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++.

cratermoon 5y ago

It's almost impossible to really lose anything once it's committed to git. Just look at the efforts it takes to really remove accidentally committed secrets. The hard part is understanding how to get a reference to the thing you want to get back, how to restore it to its proper place in the history, or at least to a reasonable place, and how, if it's been pushed to a shared repo, for other developers to get their local clone properly sync'd up without their local work getting shoved off into some hard-to-reach reference.

vzaliva 5y ago

May I have it in Magit, please?

snackematician 5y ago
Magit's wip-mode seems similar in some respects: https://magit.vc/manual/magit/Wip-Modes.html https://magit.vc/manual/magit/Wip-Modes.html I haven't tried it, but have been meaning to look into it. Would be curious to hear experiences of anyone who's tried it, and how it compares to the OP.

vgaldikas 5y ago

Shouldn't the article be called "We can undo better" :D

workethics 5y ago

I feel like an outcast after reading all the comments here. I've never really had issues using git. I didn't realize so many people had trouble with it.

ggregoire 5y ago
That's what I was thinking. I barely understand how git works but I've never had issues neither. Could be because people don't have a good workflow. Mine is as simple as: - git pull -r (to pull & automatically rebase commits from the common branch) - git checkout -b (to create my own feature/debug branch from the common branch) - git add -A/commit -m/push (to add, commit and push… I usually let my IDE handle that part) - git rebase (to rebase commits from the common branch) - git reset (to squash all the "WIP" and "fix" commits on my feature/debug branch. I then do 1 or 2 clean commits and push -f) - finally I do a merge request, or directly git cherry-pick the commits to the original branch if nobody else works on the project I've been doing this for years and it just works.
kingaillas 5y ago
Meanwhile, I refer to Git Flight Rules (https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules) on a weekly basis. Especially the branches section - somehow I'm checking in or pulling from the wrong branch, or branching from the wrong parent, and cleaning up is so tedious/annoying. I'm gonna check out this "git undo" command in the article.

MehdiHK 5y ago

Git Tower GUI app has undo feature too, which is very handy. They announced it in this post: https://www.git-tower.com/blog/how-we-built-undo/ https://www.git-tower.com/blog/how-we-built-undo/

chagaif 5y ago

I'm still scared of using got undo

Vaslo 5y ago

I used GIT recently for tracking an SSIS package and despite many commits I still have no idea whether I should use a rebase or a reset or a hard reset. Reading the manual does not help. I just simply want to undo a mistake. Glad I am not the only one who feels dumb about this.

robin_m 5y ago

Quick tips for people that find git confusing: - Use a recent version of git. The error messages have improved a lot, have been localized (unless you do `LANG=C git …` to be able to search it on internet), the UI has improved, `git status` is more helpfull, … - Create an alias for `git log --graph --decorate --oneline --all` or something fancier with `--format`. `--graph` should help you a lot to visualise stuff. - Don't use `git reflog` but `git log --graph --reflog`, it's much easier to visualize. - Never use `git checkout`, but `git switch` and "git restore` that were introduced in git 2.15 IIRC. They are much less confusing and error prone. - `--patches` (`-p` for short) can be used with `add`, `restore`, `reset`, `log`. It helps a lot with commit hygiene. - Most complex rebase are easier to do with `--interactive` (`-i`). - Activate `rerere` in your git config (it will reduce conflict merges during rebases).

neycoda 5y ago

git --stop --being --stupid

neycoda 5y ago

This is completely unnecessary. I've been able to fix every mistake I've seen in the last 5 years with variations of git diff, git branch, git merge, git reset and git rebase and their options, and I've seen some horrific doozies from newbs and pros.

0xbadcafebee 5y ago

Git is just a horrible user interface, period. Linus named it "git" because it's clearly kind of stupid. But it works for many people. Other version control systems are much better for beginners (especially centralized ones). But mainly they are easier because they're designed to be user friendly. But nobody's going to solve the major problems of Git any time soon, because you can eventually get Git to work. This is a persistent problem I see all over the tech landscape. We live with crappy solutions because trying to make a better one is way more work than just dealing with the bad one. Progress isn't impossible, it's just tedious.

ori_b 5y ago

This sounds like an idea that I can implement in 9front's native git reimplementation pretty easily. May be my next weekend project.

jacobsenscott 5y ago

Git is hard to use mostly due to "clean commit history" cargo culting. The commands that cause the most trouble are the command that re-write history, and there really is never a good reason to use them beyond "I want my commit history to look like a line".

cerved 5y ago
Tbf, rewriting local history makes a ton of sense but with great power comes great responsibility

Milkman128 5y ago

Team explorer saves my days. Playing with command prompts for simple tasks is never ideal

bedobi 5y ago

A huge reason why undoing things in Git get needlessly confusing is using merge commits in the first place. I've always advocated ONLY squash commits to master. It makes things much, much easier to understand, and much, much easier to undo things with equally easy to understand regular git reverts.

radres 5y ago

I can't believe how so many devs are hating git. It is one of the best tools in software engineering.

shruti346 5y ago

I was thinking same yesterday coz I did a wrong commit

alxndrr 5y ago

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/ https://www.git-tower.com/blog/how-we-built-undo/

arxanas 5y ago
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 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...)

johnisgood 5y ago

So many people that have issues with git, yet it still is quite popular... everywhere. I wonder if they would do any better with another VCS. I do look forward to pijul.