How to encourage contributors to choose rebasing over merging?

Question

Here's a chunk of commit messages from our repo. It's mercurial but I believe in this context git will be relevant as well:

Viktor Bubnidze TEST: chat send url fix changeset
Kate Gunicky    PROJ-15754: [work-space] Chat Section CSS issues
Vadym Malan     Merge 
Vadym Malan     TEST: char send url test
Ron Cosby       Merge
Ron Cosby       Merge
Ron Cosby       Merge
Ron Cosby       Merge
Ron Cosby       PROJ-15711: Fix the jsdoc template 
Anna  Flint     Merge

See what's going on - each time user updates while goint to push and found that repo is outdated just merges. This creates informational noise and makes log reading less comfortable. Also, merges to my understanding are not completely cheap in terms of disk space.

My question is - what can be done to encourage contributors to use rebase whenever it is possible. For instance, it's relatively easy to introduce hooks that forbids merge commmits at all. In fact, there are already lot of restrictions in our project - like commit message naming etc. I'm not sure that being restrictive is the best thing to do in this particular case.

People are choosing merges because it is the cheapest strategy for syncing. If some other strategy will work for them and be more pleasant - they'll just switch to it.

The thing is I can not come up with any elegant "kind" solution for this. To be completely honest with you, the tempation to play as a dictator is quite strong. But I just want to learn somthing new. Something, well, more peaceful.

Answer 1

Ask for meaningful commit messages

The problem does not come from using merge commits instead of rebase in this particular case. It is the lack of meaningful commit messages. For example, without seeing your repository, this could very well be a merge commit:

 Ron Cosby       PROJ-15711: Fix the jsdoc template

But contrary to the other commits, this one has a clear meaning. Similarly, imagine you have:

 Vadym Malan     Rebase

This rebase commit is the same kind of noise as current merge commits (edit: assuming this was obtained by collapsing commits and changing the message, of course). Granted, the tool design is such that merge commits have automatic messages and rebase do not, but that is in no way an argument to force people to use rebase, because rebasing does not automatically prevent you from having noise in your history.

It is easier to commit merges without thinking about a message, because there is a default message for merges. For example, originally, git would not even fire the editor for merge messages, which was recognized as being a design error:

[...] my main issue is that git makes it way too easy to have bad merge messages.

^{(Linus Torvalds)}

This has been fixed, but still, the default message should not be used. Note also that the default message in git at least indicates which branches are being merged, which could provide more informations than simply "Merge".

Also, merges to my understanding are not completely cheap in terms of disk space.

No, they are as cheap as regular commits, don't worry. To be more precise, even if they take more space, this is not important. You don't decide to rebase instead of doing a merge commit because it could save you a couple of bytes.

How is it relevant to your question?

You said:

People are choosing merges because it is the cheapest strategy for syncing. If some other strategy will work for them and be more pleasant - they'll just switch to it.

Imagine you tell your team:

"Team, from now on we want to have descriptive commit messages. Yes, Ron, that includes merge commits. You better follow this policy, or else* ..."

(* this part is optional)

Then, your merge-oriented people will:

• see it as a burden and decide to rebase instead;
• or, they are okay with the new policy and will write good commit messages.

You win in both cases.

Answer 2

One way of 'hiding' the merge change sets is to use Mercurial Queues. It is an extension currently being distributed along with Mercurial.

In short, they are mutable change sets, known as patches in a patch-queue. Instead of having to merge, your users can rebase and then apply the patch or patches they want to push on top of the tip of the rebase, finalise the patch(es) and push.

You still will have to educate your users to use the patch queue properly.

Maybe there is a different reason for your users to merge...

A distributed version control system like Mercurial implies merging, that is the whole idea of it. People can work disconnected and at a later stage merge their work into the main branch. Mercurial makes merging easy, so I'm not surprised that your users use it - it is the path of lest resistance.

Merging is also (almost) impossible to prevent. Say, all of your users have a commit hook installed that checks upstream before committing. Then your users have to rebase before they can commit and thus prevent merges. If two users rebase first and then commit at the same time (which is allowed by the commit hook) one of them will still have to merge.

To prevent this, a number of the teams at my current work-place use commit & push tokens. Only the person who owns the token, is allowed to commit and then push. This prevents merging (at least most of the time).

On one of my previous work-places, they used a gatekeeper. The central repository was always closed. Only when your code was reviewed and approved (this involved an official document that required signatures of multiple people), the gatekeeper allowed you to commit and push. This was a very elaborate process.

You see, there are several ways of preventing merging ;-)