Hacker News Reader

Comment by echlebek | Hacker News Reader

As a former mercurial user, it absolutely drives me nuts when people rebase already-pushed commits. I get that this is the norm in a lot of git workflows, but it still makes me twitch!

I prefer to rebase liberally before pushing commits, and then merge once commits have landed in a shared repo or been pulled by others. No git --force necessary.

View on HN

I assumed the standard rebase practice was to rebase only local branches, and only if you intended to continue working on a feature branch over updated versions of your target branch without introducing superfluous merges. Consequently, although I've been using rebase for a couple of years now I never had to use git --force to handle a rebase.

I only sometimes use force because I "share" the branches with the automated CI system so they are not strictly local and may need force pushed after a rebase, but no other human will be inconvenienced by those pushes.

That's where Mercurial phases and publishing repositories improve UX a lot. Developers can have their forks with non-publishing repositories that indicate commits that are not in public state and can be easily edited. This is such a great concept.

Some git hosting services let you turn off the ability to accept force-push. Github and Bitbucket both support this. That's usually the first thing I do when setting up a shared repo for a project.

Uhm, changing published commits is not recommended in git, maybe except private repos or branches. Could you point to specific workflows that encourage this?

Reply on news.ycombinator.com