Re: VCS comparison table
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Oct 17, 2006, 23:24 UTC
- Message-ID
- <200610180124.28048.jnareb@gmail.com>
- In-Reply-To
- <45355EEE.3060105@utoronto.ca>
Aaron Bentley wrote:
[...]
Show 16 quoted lines
>> 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