[Kde-scm-interest] Re: Usage of pull rebasing and merges

[Oswald Buddenhagen]

On Wed, Feb 09, 2011 at 02:27:31AM -0600, Boyd Stephen Smith Jr. wrote:
> I agree with your definition of a good history, but git does no favors by 
> automatically committing merges.  The merge is another state and needs to be 
> tested before it is actually committed.
>
you can amend a merge like any other commit.

but i don't agree with the definition in 99% of the cases, because
rebasing is usually a trivial operation, and there is no reason to
believe the rebased commits would behave differently than the original
ones when the end result is still correct. when the rebasing causes
non-trivial conflicts, you have a point. other than that, merges of
short branches are only useful as "markers" (which is utterly pointless
in the by far most cases, as the branches are just one or two commits
long after they have been properly reshaped).