Re: What a modern collaboration toolkit looks like

[Miles Bader]

Eli Zaretskii <address@hidden> writes:
>> > To start using git, we need first get to the point the Linux kernel
>> > developers are at: lots of developers independently developing all
>> > kinds of extensions.  _And_ we need a head maintainer who works on
>> > nothing else but integration of features she likes into the product
>> > that is eventually released.
>> 
>> No we don't (how on earth did you reach that conclusion ?!).
>
> AFAIK, this is how Linux kernel development works, and that is the
> single most important basis for the git philosophy.

There's a common kernel development style, and git is good at it -- but
git has been influenced by _many_ people, and as a result, supports many
different working styles quite well (and even kernel development is not
so homogeneous -- various sub-projects use a more centralized
development style, and yet can inter-operate seemlessly with the main
kernel).

>> Git, like most modern source control systems, is pretty much a
>> _superset_ of CVS, and can happily be used with a CVS-like "central
>> server" (where it still handily beats the pants of CVS in almost every
>> respect).
>
> IMO, it hardly makes sense to switch, then, and it's not what Tassilo
> had in mind and put in writing, AFAIU.

Again:  it still handily beats the pants of CVS in almost every respect
[when used in "centralized" fashion].

_And_ it gives much more flexibility to developers.  For instance, I may
normally push changes to the central repository many times a day, but if
I go on a vacation, I can bring my laptop and _continue_ commiting
changes "locally", and then push them all to the central repository when
I get back (preserving all commit boundaries of course).

Git allows many development styles to interact seamlessly.  I think
that's a good thing.

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.