He says he has no need for it. But then again, he has a point: why should he need this? He manages to get his work fine without it. Indeed, most people find a DVCS more complicated to understand than a CVCS.
There's an inherent complexity with concurrency that a centralised, linearised VCS does not exhibit.
I moved our entire company from SVN to Git with no support issues to speak of. None of our developers had an issue with it at all, and no one lost any work just because they fundamentally misunderstood how Git worked.
In the end, it sounds like Stallman needed to read any basic 'how to git' document on any blog anywhere and it would have explained to him what he needed to know to not lose his data, and maybe 'why to git' to figure out the benefits of 'commit' vs. 'atomic commit and push'.
This honestly sounds like a manager saying 'from now on I want everyone to log when they arrive to work into this Excel file shared from my laptop so that I can look at it and see how we're doing attendance-wise', completely disregarding whether that approach is feasible or worthwhile, if there's a better solution, or if it's just going to confuse and frustrate everyone.
I never thought I would compare RMS to the clueless manager stereotype, but this 'I don't understand it so it's obviously a problem' attitude is just… ignorant.
This is misleading. He thinks emacs' interface that genericizes VC should have git commit and push be treated as combined and atomic, largely because he thought BZR worked that way by default (rather than actually being configured that way particularly for the emacs project).
After much "wow, that would be awful" convincing by people who are more familiar with git and could articulate why one commits privately on purpose, RMS later changes his stance. What I saw him eventually say was that commit should remind the user that they may need to push to publish (and emacs should add a vc-push command), which is quite reasonable.
To be fair, this is the issue with trying to put a generic interface over systems that don't -quite- work the same way. You tend to favor lowest common denominator. And sometimes there's not a "least surprise" workflow for everybody.
The wind of the conversation now seems to blow towards one workflow for vcs and one slightly augmented one for dvcs, which seems correct.
This exchange makes me think Stallman isn't a git power user, committing without pushing is common useful and awesome. He also seems to speak exclusively in terms of the Emacs integration.
9 comments
[ 4.6 ms ] story [ 29.9 ms ] threadThere's an inherent complexity with concurrency that a centralised, linearised VCS does not exhibit.
In the end, it sounds like Stallman needed to read any basic 'how to git' document on any blog anywhere and it would have explained to him what he needed to know to not lose his data, and maybe 'why to git' to figure out the benefits of 'commit' vs. 'atomic commit and push'.
I never thought I would compare RMS to the clueless manager stereotype, but this 'I don't understand it so it's obviously a problem' attitude is just… ignorant.
(and I care about what RMS thinks)
After much "wow, that would be awful" convincing by people who are more familiar with git and could articulate why one commits privately on purpose, RMS later changes his stance. What I saw him eventually say was that commit should remind the user that they may need to push to publish (and emacs should add a vc-push command), which is quite reasonable.
To be fair, this is the issue with trying to put a generic interface over systems that don't -quite- work the same way. You tend to favor lowest common denominator. And sometimes there's not a "least surprise" workflow for everybody.
The wind of the conversation now seems to blow towards one workflow for vcs and one slightly augmented one for dvcs, which seems correct.