VCS comparison table

[Jakub Narebski]

Aaron Bentley wrote:

[...]

>> 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.
> 
>> 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.
> 
>> 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