What is acceptable as 'open-source'?

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> On Thu, Aug 28, 2014 at 3:14 AM, Marko Rauhamaa <marko at 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