I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions.
Pretending the average user will know how to get things back to how they are is silly.
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.
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.
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
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.
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.
"Pretending the average user will know how to get things back to how they are is silly."
The reflog is faaar more complicated to use that any of the day-to-day git commands.
Getting folks to use it would be very difficult due to network effects however.
After having rewritten history locally (with Mercurial this is easy, powerful, safe and with a lot of tooling available) everything you need to do is doing an hg push --force.
For one, hg histedit with its curses interface (default since 4.9) is sweet.
Linus wouldn't claim to be a brilliant designer of user interfaces. It's totally conceivable that somebody could come along and develop a new way of talking about Git's functionality, implemented by a new "porcelain". Changing the vocabulary, creating a more comprehensible map of the internal logic of the thing...
In reality, git is actually far from ideal tool, with its own weak points and use-case scenarios which it simply not or badly supports. So it's never "just you" don't feel bad that it's "hard." On top of this, even the scenarios that it supposedly "good" supports demand sometimes totally "illogical" combination of the names and parameters.
git is used in spite of its flaws for different reasons. Some actions are really very fast, faster than by the competition. Sometimes that is a reason enough. Another is -- we have to use what our colleagues use. Even another: once you become familiar with it, even if you were aware of the weirdness, it can stop annoying you. Still to be able to realistically compare it with something else, you have to at least try it. And that something else too.
Anyway, once you get rid of the actual complexity in git, it's an easy step to work on the added complexity to the UI.
https://www.git-scm.com/docs/gitrevisions#Documentation/gitr...
git branch local/foo