[larzang]

Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.

[recursive]

I have been using git for years, and have never rebased once. I'm kind of scared to try, perhaps irrationally. Rebasing seems to change commit relationships in a way that seems like it may be difficult to untangle if it later differs with someone else's clone.

I would also like the ability to see a nicely curated set of changes. This mostly exists in the diff tabs of a pull request. If this were to be a first-class feature in git, it seems appropriate to be in some layer other than commits, but alas, that doesn't exist.

[WalterSear]

Rebase is best done before you share commits with anyone.

I routinely do an interactive one before PRs to clean things up.

[recursive]

Is there a reliable way to know whether any of the involved commits have been pushed anywhere? I would probably usually know off the top of my head, but not always.

[rakoo]

Check your local branch and the associated remote branch in your git log.

If the remote branch is an ancestor of your local branch, you have some commits that haven't been pushed yet and you can "play" with them.

If the remote branch and the local branch point to the same, you can't rebase without potentially impacting someone else.

If the remote branch and the local branch have diverged, it's already too late.

[outsomnia]

Rebasing one tree on another is a pretty specific thing, you may not need to do it very often.

But casually manipulating the order of, or combining or filtering, patches near the top of the tree is something else. There are tools for this, eg

https://github.com/stacked-git/stgit