I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`.

I've almost never needed to run `get reset before-rebase`. But I have often done `git log -p before-rebase` and compared that to the post-rebase state of the branch, to ensure that the merge-conflict resolution(s) that came up during the rebase haven't accidentally introduced an unintended change.

Diffing diffs is so valuable for that reason, seriously underrated. Once I even found a use case for diffing diff diffs.

I also often wish to edit commits or resolve rebase conflicts or whatever by editing the patch rather than the files.

Seconded, I diff diffs all the time after a rebase or after merging the `develop` branch into my feature branch (which I sometimes do when the rebase would have produced so many merge conflicts over so many commits that it's just not worth the hassle, even using rerere — and since our team routinely uses the GitHub "Squash and merge" button, the develop->feature branch merge gets squashed away and doesn't end up showing up in the develop branch log once the PR is merged). It's the best way I've found to double-check that I didn't made a mistake in merge conflict resolution: does the diff from branchpoint to before-rebase still match the diff from new branchpoint to after-rebase? Yes? Then I probably didn't screw up the merge conflict resolution.

Hey yo,I heard you like diffs, so I put some diffs in your diff so you can diff your diff while you diff!

Sorry, couldn't resist. The xzibit was too strong in your comment.

After a rebase, mybranch@{1} refers to the previous location of mybranch, so you don't need to manually track these before-rebase branches etc.

(In practice I find this syntax super annoying and usually end up typing `git reflog mybranch` and then copy-pasting the commit hash from the output).

TIL!

> but branches can be moved around with less ceremony than tags

`git tag -f` to move a tag.

Personally, I just do `git show` when I'm feeling cautious, but I can generally just scroll up to find the last `git commit` I did with the hash in the output. `git reflog` should also have record of it, so everything else is kind of extra.

Good point, that's no more ceremony than moving a branch. I guess I've just gotten "branches are movable tags" so deep into my hindbrain that I absorbed "tags are hard to move". But that's not actually true, and for what I'm doing (save this point in history for a while) a tag makes slightly more sense, semantically, than a branch.

git tags are more lightweight than they seem. It's why the UX defaults to not sharing tags, with the idea that you may need/want local-only tags. They also share the same "namespace" that you could have tags like `myname/some-personal-tag`. (I've used `project-name/v1.2.3` style tags in monorepos rather than solitary versioning the entire repo.)

`git tag -d` deletes tags and `git tag -f` moves them (forces them to change).

For the most part whether you prefer a branch or a tag for temporary marks is an aesthetic choice, though the twist is maybe using annotated tags. The annotated tag allows you to leave a commit message for yourself why you made the temporary tag in a way that you can review later. Just like optionally adding a stash message (which also reflects why stashes work under the hood more like tags than like branches).

This is the exact same thing I do, though with the prefix "pre-rebase/"

The fact that I misread that as "prebase" (I've done the same misreading with "prerelease" in the past, too) is why I prefer `before-rebase`, even though `pre-rebase` is slightly faster to type.

Do you use git reflog?

One can also use that, or just `git log -n1` and taking note of the commit hash. So many options.

Fun fact: you don't even need the `-n`. `git log -1` does the same thing, for any number.

    -<number>, -n <number>, --max-count=<number>
        Limit the output to <number> commits.

For scripting: git rev-parse HEAD

I do when I forget to run the git branch comment before. But I find it still hard to understand exactly which commit to reset to in the reflog.

The branch reflog (git reflog <branchname> or git log -g <branchname>) is a lot easier to follow in the case of rebase than the HEAD reflog (which gets an entry for each commit that gets checked out / applied).

You don't even need to set a safety tag like that anywhere in git, the reflog does that for you automatically.

No need for that even. Just git reflog and rewind back to any spot your want!

> `git rebase --abort` exists

Exactly. 50% of the times I type git rebase it is followed by --abort.

jj undo

You can't get simpler than that.