DVCS Comparison: On mainline merges and fast forwards

DVCS Comparison: On mainline merges and fast forwards has a discussion about whether 'fast forward' is a "better" method for merging in a distributed topology.

I can understand where he is coming from, and we respect that some users prefer other workflows. Bazaar even has direct support for 'fast forward' with 'bzr merge --pull', and with our aliasing functionality, you can set:

[ALIASES]
merge = merge --pull

In ~/.bazaar/bazaar.conf and change the default meaning of 'bzr merge'. However, I still fall of the side of the fence that fast forward should not be the default.

I can agree that if you have 2 people collaborating on the same feature that you would want fast forward. Though I would argue that is because they are effectively working on the same branch. For my personal workflow, I have a different alias set:

log = log --short -r -10..-1 --forward

What this means is that when I type 'bzr log' I see just the mainline commits of a branch, without the merge cruft. (Where I define the merge cruft as the individual revisions that make up a feature change, not the 'merge foo' node.)

Take this view of bzr.dev:

3466 Canonical.com Patch Queue Manager 2008-06-02 [merge]
    (jam) Give Aaron the benefit of bug #202928

3467 Canonical.com Patch Queue Manager 2008-06-03 [merge]
    (Martin Albisetti) Better message when a repository is locked.

3468 Canonical.com Patch Queue Manager 2008-06-03 [merge]
    (mbp) merge 1.6b1 back to trunk

3469 Canonical.com Patch Queue Manager 2008-06-04 [merge]
    (mbp) Update more users of default file modes from control_files to bzrdir

3470 Canonical.com Patch Queue Manager 2008-06-04 [merge]
    (Jelmer) Move update_revisions() implementation from BzrBranch to
      Branch.

3471 Canonical.com Patch Queue Manager 2008-06-04 [merge]
    (vila) Split a test

3472 Canonical.com Patch Queue Manager 2008-06-04 [merge]
    (jam) Fix bug #235407, if someone merges the same revision twice,
      don't record the second one.

3473 Canonical.com Patch Queue Manager 2008-06-05 [merge]
    Isolate the test HTTPServer from chdir calls (Robert Collins)

3474 Canonical.com Patch Queue Manager 2008-06-05 [merge]
    Add the 'alias' command (Tim Penhey)

3475 Canonical.com Patch Queue Manager 2008-06-05 [merge]
    (mbp) #234748 fix problems in final newline on Knit add_lines and
      get_lines

You get to see a nice short summary of everything that has been happening (in proper chronological order.) Admittedly, seeing "Patch Queue Manager" on each of those commits is less optimal (which is why we add the author names.) That is just a temporary limitation of our PQM. Bazaar already supports setting an --author, separate from the committer, we just need to teach our integration bot to use it.

The big difference, IMO, is whether you are bringing in someone else's changes to enhance your work, or whether you are collaborating on the same item. I would argue that collaborating on the same item is slightly less common. It also depends what you do with the merge commits. Just saying "merge from branch A" is certainly not helpful. But when you can say "merge Jerry's changes to Command.foo", it can indeed be helpful when tracking back through and figuring out where and when "foo" changed, without being lost in the forest for having too many trees.