> Merge is done by a classic 3-way diff. It looks at all the changes > that occurred on the path from A to B and applies those same changes > to C. (A in this case would be the most recent common ancestor of B > and C). > > How would cherry-picks factor into this? >
Sorry, maybe I'm confused. I'm not at the moment talking about the 3-way diff algorithm, but the step before that in which the GCA (your 'A') is determined. You said that the GCA calculation does not consider cherry-pick merges. I'm wondering whether there is a deep reason for that, or if it's just because no one has yet had a need for it. Perhaps it is because if cherry-picks are considered, then you'd have to determine a GCA for every file rather than for the check-ins as a whole, and you believe this will be too slow? Or maybe there is some deeper logical problem that I haven't considered. In my initial example, if the cherry-picks were considered then the 'beta' leaf would be the GCA for my test file, so the merge would be a trivial one (simply take the current 'trunk' leaf as the new file data). Eric
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
