3 ms·
This is technically true, and a common reposte when talking about preservation of history edits. Unfortunately, the reflog is confusing and hard to use correct
by brandmeyer 7y ago
This is technically true, and a common reposte when talking about preservation of history edits.
Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. It also just so happens that its when an interactive rebase goes awry that I really want to reach for the reflog to fix the damage.
- Stratoscope 7y agoSmartGit does a brilliant job of integrating the reflog and stashes into the rest of Git. The history log window has a Branches panel, which is a tree view with subtrees for your local and remote branches. Below those is another subtree of any stashes you have saved, and then a Recyclable Commits checkbox. When you turn on Recyclable Commits, every commit in the reflog shows up in the history tree just like any other commit. You can see exactly where they diverge from your other branches and can work with them as you normally work with any commit. Same thing for stashes: check one and it just shows up as part of the commit tree as if it were a normal commit. I've used SmartGit for years and highly recommend it over the Git command line for the way it gives you so much more insight into the state of your repo.
- u801e 7y ago> Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. When you run git reflog after rebasing, you will see lines like the following: 29d82ac HEAD@{6}: rebase -i (finish): returning to refs/heads/your-branch 29d82ac HEAD@{7}: rebase -i (fixup): Commit message 2 4f8e996 HEAD@{8}: rebase -i (pick): Commit message 2 f3a954e HEAD@{9}: rebase -i (pick): Commit message 1 f74b8a5 HEAD@{10}: rebase -i (start): checkout origin/master The line listed after the one that has rebase -i (start) is the commit you were on before you started the rebase. If I screw up a rebase, then I will stash any uncommitted changes and run a git reset --hard to the commit listed below the rebase -i (start) commit I see in the reflog and start the rebase again.
- chrisweekly 7y agoYes, git stash is awesome! I use it all the time to "snapshot" my WIP and/or to quickly get a clean working tree when taking an interrupt to work on something in a different branch. (`gs` alias for `git stash save -u`, along with `grs` for `git reflog show stash` -- which shows the commitish for each stash...) I see the stash as kind of like a private remote, in that I can freely put whatever messy or experimental or half-baked WIP I like, gaining the benefits of a commit without inflicting it on anyone else.
- eridius 7y agoHEAD and the branch have separate reflogs. Each step of an interactive rebase adds a separate entry to HEAD's reflog, but the branch's reflog only ever gets a single new entry when the rebase is complete. So you can run e.g. `git log -g master` and skip the rebase intermediate steps. It is rather unfortunate that there is no convenient documented shorthand for "show me the reflog of the current branch" (`git log -g` gives you HEAD's reflog). That said, after a bunch of experimentation, it seems like `git log -g '@{0}'` will give you the reflog for the current branch. Apparently this works because e.g. `git log -g '@{2}'` gives you the reflog for the current branch skipping the first 2 elements.
- dmitryminkovsky 7y agoThanks for pointing this puts I didn’t realize/notice this until recently. And it makes a lot more sense than having one reflog. I would have liked to have known sooner.