Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "The Unreasonable Effectiveness Of Plain Text" video.

Git with merge workflow is easy to explain to anybody. The hard part is to help non-technical colleagues to select a plain text editor that's actually good. And no, Notepad or Word are not reasonable options for writing plain text files. That said, I think rebase workflow is clearly superior to merge workflow if your team can handle it.
95
@szaszm_ Bitkeeper demonstrated to Linus that having a good version system is actually superior to tar balls and patches on LKML. However, Linus specifically engineered Git to share nothing with Bitkeeper to make sure that Bitkeeper cannot claim that Git is infringing their copyright. As a side-effect, Git improved on some limitations of Bitkeeper.
58
@szaszm_ I don't remember exact list but the most important stuff is what's included in a single commit (only tree hash + time, author name and author email), how the commit is named (SHA-1 hash of the contents) and the fact that branches and tags are namespaced so that every developer in a big project can still have local branch called "test" without a conflict. (For a comparision, Mercurial has tags, branches, named branches and bookmarks instead of Git having only tags and branches. Mercurial also includes the name of the branch in the commit metadata so you cannot rename any branches after the fact unlike in Git.) You're correct that simply rewriting the code from scratch would avoid copyright infringiment but you have to remember that developers also had to accept EULA to use the Bitkeeper and creating something too similar could have been an EULA breach. I haven't seen the Bitkeeper EULA the developers had to accept so I cannot tell for sure, but from the descriptions I've seen it appears that the EULA disallowed reverse engineering the data structures or logic of the code.
10
@AllanSavolainen Merge conflict for rebase and regular merge is identical. However, in case of rebase, you resolve the merge in parts (that is, each conflicting patch at a time) instead of one big merge at the end. If you have atomic commits, solving the rebase conflicts is typically easier than solving one huge merge conflict at the end (which happens with regular merge). And as a bonus, the version history is much easier to understand if you use rebase workflow. That said, an experienced team using rebase workflow may use regular merges every now and then if that makes more sense than rebasing a branch. If you avoid rebase because you don't know how to use it, you're limiting valuable options from your toolbelt.
6