[saltedmd5]

Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS.

Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).

[kazinator]

That is not correct; rebase per se doesn't rewrite history.

Rebase is basically just cherry picks. You can rewind a branch and then cherry-pick, so that the picks are non-fastforward. That's rewriting history. Cherry picking without rolling back is fastforward, and so doesn't rewrite history.

The Gerrit review system on top of Git is based on cherry-picking; it doesn't rewrite history.

If some developers are collaborating on a feature which is on a branch, they could agree from time to time to rebase that branch to a newer mainline.

Whether or not that is done by a history rewrite simply hinges on whether the same branch name is used for the rebased branch or not. The rebase is what it is: if you plant that rewrite as the original branch name, then you have a non-fastforward change. If a new branch name is made, then it isn't a rewrite.

Merging a feature branch onto a trunk can always be done in a fastforward way using rebase/cherry-pick.

Rebasing is provably simpler than merge. Merge depends on complications in the git object representation which could be removed while rebase remains what it is. If you only ever rebase, you never see a commit with multiple parents; the feature is superfluous and turns git histories into hairballs.

[saltedmd5]

AFAIK rebase always rewrites history. If you rebase your feature branch, you have at least rewritten the history of the local branch even if you then delete it and push to a new remote branch. The trunk will subsequently get a FF merge.

Rebase might give you a "simpler" end result in terms of what the history looks like but conceptually it is much less simple in terms of its mechanism and its implications (e.g. rebasing a branch with multiple contributors screws up the audit trail as it now looks like they made their changes at a different time and in a different context to when they actually did) than the idea of a graph with two branches and a merge commit.

I have seen teams with limited git experience switch from habitually rebasing public branches to accepting merge commits and suddenly cure a whole host of workflow problems.

If you can rebase directly onto a fresh branch (not something I've seen) then I am fairly sure that that's not part of your average workflow - establishing new branches every time you want to update from trunk comes with its own communication overhead too.

[yeukhon]

Simple or not, it's a subjective. As you said it:

> > it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing

I am taught git with rebase (though merge when I use hg) so I am already too used to it. Branching then rebase is not that difficult if you keep your workflow consistent and quick iteration. You should be up to date whenever possible. Amending and rewriting history/comment also requires using rebase.

YMMV.

[muxator]

mercurial has "phases", which means that it allows free rebasibg and history rewriting for changes that are still not public.

As soon as a tree is pushes, those changes become public, and you need to explicitly force the history rewriting operations.

This is part of the " safe defaults" approach of mercurial.