Re: VCS comparison table

Aaron Bentley wrote:

[...]

quoted

So generating an extra "merge" commit would be actively wrong, and adds
"history" that is not history at all.

It's not a tree change, but it records the fact that one branch merged
the other.

quoted

It also means that if people merge back and forth from each other, you get
into an endless loop of useless merge commits.

You can pull if you don't want that.  We haven't found that people are
very fussed about it.

quoted

There's no reason _ever_ to not just fast-forward if one repository is a
strict superset of the other.

Maybe not in Git.

Think what the existence of merge commit is for. It is a place where
we can record how we resolved conflicts. It means: we _merged_ (joined)
two (or more: does bzr support octopus merge?) lines of development.

Merge commit in fast-forward case is only marking "here we did a pull"
(here we downloaded from other repository). It is just a marker which
place is in reflog, not in history. It is only cluttering history.


Besides one of canonical workflows used and encouraged by git is:

 * repository A stores does it's own work on branch 'master',
   and fetches changes from 'master' branch of repository B
   into branch 'origin'. "git pull origin" when on branch 'master'
   fetches changes from 'master' branch of repository B (requiring
   usually that it fast-forwards) into branch 'origin', then
   merges branch 'origin' into branch 'master', automatically
   creating merge commit message.

 * repository B does it's own work on branch 'master',
   and fetches changes from 'master' branch of repository A
   into [tracking] branch 'origin'. (...)

Instead of pull/fetch, we could use push.
-- 
Jakub Narebski
Poland