On Fri, Nov 01, 2019 at 03:01:16PM +0300, Dmitry Alexandrov wrote:
Adam Spiers <g...@adamspiers.org> wrote:
On Mon, 28 Oct 2019 at 00:12, Taylan Kammer <taylan.kam...@gmail.com> wrote:
On 28.10.2019 00:51, Richard Stallman wrote:
I don't know how CVS handles merge conflicts, but the Emacs extension Magit is
a very nice front-end to Git
I strongly recommend any emacs user who switches to git to try it as the
learning curve is very gentle and the gains in efficiency are huge.
On the other hand, one may strongly recommend anyone who switches to git _not_
to try it, as there no reason to complicate the process by switching both
backend and frontend at once, when he has Emacs, which transparently provides a
uniform interface to all VCSes.
There *are* reasons, including the gains in efficiency I mentioned. It's a
tradeoff between complexity and efficiency. Each person should be empowered to
judge what is best for them personally, based on factors like how important it
is to them individually to have a single interface for all VCSes, vs. having
arguably the most powerful git frontend out there. Therefore IMHO it is more
helpful in these discussions to offer alternatives to consider rather than to
recommend ignoring alternatives.
Maybe if rms is too busy to spend a little bit of effort learning a new
interface, and still regularly needs to operate with CVS etc., then VC might be
the right choice for him. But an informed decision would include consideration
of reasonable alternatives like magit.
git uses fundamentally different paradigm to the model on which VC was
designed. One of many examples of this is that it requires staging changes
before committing them. My personal opinion is that it makes no sense to use a
version control frontend which is totally outdated relative to the backend in
question. I enjoyed using VC for many years (and hacked various extensions to
it), but it hasn't kept pace with the evolution of modern VCS frontends. I
estimate that its functionality is probably about 5% of what magit offers.
