[lnguyen]

The strategy isn't the issue. It's whether it fits with the process you've set up.

If you do code-review on the contributions/pull requests then I can see where the merge-often strategy causes issues. The auto-generated merge commits don't give you the context of the updates that are pulled in and will lead to having to spend time going back through the commit tree. It may not lead to the introduction of issues or regressions but you can't be sure.

However, if you're set up as a small team with good internal communication or a high level of trust, then merge-often can be a good thing in that you usually aren't left with big merge issues to deal with and you're more likely to have any conflicting updates fresh in your mind.

[lucisferre]

We solve the problem with rebasing. If it's not part of the main branch then it's not part of history, so rebasing to organize the pull request makes sense.

[lnguyen]

Rebase works great when you need/want to preserve he revision history. It's probably the ideal process to put in place if you can mandate it.

One thing to keep in mind is that it might lead to a number of merge conflicts that may be difficult or tedious to resolve depending of how the branches have diverged. Merging may avoid these.

[lucisferre]

Why would regular merging avoid this more than regular rebasing? The result is the same.