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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html