On Sep 9, 2008, at 8:44 AM, Jakub Narebski wrote:
This can also lead to replacing origin <b> <a> origin <c> <b> by origin <c> <a> for squash merge, or squash in rebase interactive.
And, incidentally, the above representation will potentially mesh well with svn integration, making it possible to cleanly represent svn 1.5 merge-tracking metadata directly in git.
Unless of course one uses more complex merge strategy, which doesn't take into account only endpoints (branches to be merged and merge bases), but is also affected in some by history...
It does intuitively (but perhaps incorrectly) seem like the origin information could be used to make more intelligent decisions about automatic conflict resolution, if nothing else. Though obviously that might, as you suggest, be a pretty big departure from the way git merges currently work.
-Steve -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
