Rewriting local history seems no different than rewriting code in your editor.
Rewriting shared history is (almost) always bad.
There are a (very) few instances where you'd want to rewrite something pushed to a shared repo. One is if there's a shared understanding that that branch will be rewritten. Some examples would include git's own "pu" and "next" branches. "pu" is rebased every time it changes, and "next" is rebased after every release. Everyone knows this and knows not to base work off these branches. There's also the occasional "brown paper bag" cleanup like some proprietary information got into the repository by mistake and all the contributors have to cooporate to get it removed. But all of these take out-of-band communication somehow.
Everyone knows that it's "my branch" and that they're absolutely not supposed to use it for anything until it's merged back into master or whatever authoritative branch.
We using the forking model for bigger projects with more developers, and the branching model for smaller projects. It works out very nicely.
Also, so that if something goes awry with my dev machine for whatever reason, at least my work is saved.
Also, to make it easier for a colleague to review my code before it gets merged into something.
Also, becuase it means I can use GitHub's PR system instead of doing it on my machine (thus providing some additional record that my code got merged in, and providing an avenue for the merge itself to be reviewed and commented on).
Few things sting as bad as loosing hours or days worth of work.
(I hope I'm not alone in saying this...)
A lot of git is "magic" to many developers, and the way that rebase works is certainly one of the features poorly understood.
Yes, that's why Git doesn't allow you to push rewrites, at least not without '--force'.
Agreed. The one counterexample that I have is Github pull requests. Those are actually branches in your fork, and you do want to rewrite those when you get feedback on a pull request. That makes it easier for the owner of the repo to do the merge later.
I generally ask people to rewrite such PRs, as I’m not going to pull known buggy commits into master, even if they are followed by fixes. That is just noise.
It might also be that some commits in the PR has changed tabs to spaces or vice versa.
* In Subversion, people track patches using tools like quilt to manage them before actually putting them together into a commit.
* In Mercurial, people use `hg mq` which is like a more featureful version `git-stash`.
These are basically all ways to track a series of patches prior to 'committing' them into the code base shared with others.
What I do to avoid that is work on a separate branch, rebase against master, then review the commits on my branch after getting rid of any WIP commits and shuffling them around to make more sense. Finally, I make sure the commit messages are (a) accurate and (b) have no typos. Once I'm satisfied with that, I merge.
I treat merging as a big deal, but not committing.
