On Mon, Jul 31, 2017 at 09:29:29AM -0700, gqq nbig wrote: > I'm learning GIT and I understand GIT uses pointers to track snapshots and > it's easier to find the common ancestor of two files.
Git never tries to find common ancestors for individual files -- only for whole commits. That's because commits is what history graphs manipulated by Git are comprised of. > Whereas, subversion has to resort to property svn:mergeinfo. > > I know when I merge in svn, svn will add mergeinfo to the folder for me to > commit. If I don't let svn record mergeinfo, how suck will it be? That's exactly the situation existed in Subversion before v1.5 [1] which introduced support for merge tracking (via the svn:mergeinfo property). Basically you had to memorise (or, which is more realistically, record this information externally in one way or another) what revision ranges were merged where. Revision range to merge had to be specified by hand when doing "reintegration" merges -- that is, merging a branch into another the second time (and so on). > Is there a scenario where SVN has merge conflict while GIT merges succefully? It's hard for me to see what exactly is being asked here. Another point which complicates matters is that there are quite a number of moving parts involved. At a minimum, there's a diffing algorythms which, I presume, differ in implementation between Git and Subversion (add to this that Git has several of them, each with its own knobs, and is able to fall back to another is one failed at carrying out the merge operation). Another difference is that Subversion is able to do "partial" merges in the sense you can merge any revision range of any path -- while Git only ever operates on whole commits [*]. These things make the both systems hardly comparable on such broad scale you seem to have outlined. > Can the scenario not involve a file renaming? I'm pretty sure SVN cannot > track renaming properly. Actually, tracking renames -- by actually recording them in the change history -- is one of the selling points of Subversion, and contrary to this, Git does not record renames in any way, and uses heuristics to detect them when doing history traversal operations (such as `git log`). Again, I'm not sure how to talk about comparison here: Git does not track renames but most of the time it considers whole commits when merging, so it's okay from its point of view when a piece of information moves from one file to another. 1. https://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking [*] Well, there exist subtree merges, but those are, again, whole-commit merges, just with the added relocation of the root tree of the stuff being merged. You can also do manual tricks like doing a merge w/o recording the merge commit and then zapping all the changes the "theirs" side of the merge brings in at all paths except those in a chosen set -- emulating the Subversion's "path-wise" merging, -- and then recording the merge commit. But the resulting merge commit will still reference a whole second parent commit and will look as a regular no-frills merge to Git. -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
