On Mon, 2015-07-20 at 14:47 -0500, John McKown wrote: > I am not a git internals person. But I think you may have a > misunderstanding. git doesn't use a "dependency graph" to do > merges. ... The second is a "non fast forward" merge (SHA-1 commit > value is not in the list of commits in the remote). This is what you > are experiencing. In this case the desktop repository has changes > which are not in the remote repository. What git does, in effect, is > compares each file (contents) in your working directory with the > equivalently named file (contents) in the remote repository.
Actually Git can and does use a dependency graph for merging, as all reasonable SCM tools do. Your algorithm is correct as far as it goes, but you're missing a crucial step: when Git determines there's no fast-forward merge it uses the dependency graph to come up with the "most recent common ancestor" commit, then it does a three-way merge between your local version and the remote version with the "most recent common ancestor" as the base version. Using a three-way merge GREATLY improves the accuracy of the basic merge algorithm, because if one of the "new" versions matches the ancestor and the other one doesn't, Git can assume that it should automatically choose the unmatched version since that's the change. Only if neither "new" version matches the base version do you have a conflict. See, for example, the git merge-base command which will show the relevant common ancestors. However, obviously this doesn't help if you're trying to merge two different repositories, since Git can't compute common ancestors without walking the parent commit tree. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
