Chris Angelico <ros...@gmail.com>: > On Thu, Aug 28, 2014 at 3:14 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: >> parallel changes always result in a conflict that requires merging. > > This is a feature, not a problem. As far as most version control > systems are concerned, files aren't independent. However, the merge > should be trivially easy if it's different files that have changed.
I'd venture to say files are quite independent most of the time. That's why such merges have been facilitated to the point that negates the "feature" you mentioned. Nobody cares to take the trouble of analyzing the validity of automatic merges. I have a hunch that the "feature" has more to do with conceptual simplification and performance optimization than some theoretical principle. As a theoretical principle, it is far too blunt (unlike in Darcs). In practice, parallel, independent changes are the norm, not the exception, but git and hg just don't support them. Oh, well. The damage is insignificant if your repositories are small (~ 20 files). > If what you're concerned about is the number of merge commits, the > easiest solution is to perform rebase pulls (or to rebase a change > onto the latest tree, depending on your point of view). That's not as > easy with github's fork/merge philosophy as it is with your own > commits, but I find it's extremely easy with a pull/push model, and > not too hard with other models. I'm glad to have seen the perfect world. I can only assume that bitkeeper (whose author was among the TeamWare developers) would follow the same principles, although I haven't ever tried it. Marko -- https://mail.python.org/mailman/listinfo/python-list
