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
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
For more options, visit https://groups.google.com/d/optout.