Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

[Alan Mackenzie]

Hello, Stephen.

Sorry for the delayed reply.  My net connection went down on Thursday
afternoon, and it wasn't fixed until this morning.

On Fri, Apr 10, 2015 at 01:24:04AM +0900, Stephen J. Turnbull wrote:

> The simplest thing is to use Git like RCS: git commit, git diff,
> lather, rinse, repeat.  Even Richard and Alan do that without getting
> their shorts in a knot.  But their workflows are very workspace-and-
> mainline-centric; they don't see a need for dealing with branches, let
> alone the DAG.  They don't want to go beyond the RCS workflow.  DVCS
> fans do; branches and DAG manipulations are useful tools for many
> development activities and workflows, which Richard and Alan evidently
> perform rarely if ever.  Unfortunately for them most of the developing
> world has decided that DVCS and DAGs are good things, and they're
> finding themselves more and more isolated, even within the Emacs
> community.

Speaking purely for myself, this is untrue.  I like DVCSs and the
flexibility they (should) provide.  It is git, with its turgid command
set and options, and over-bloated (> 2MB), unsearchable manual, that I
dislike.  It is its inflexibility with regard to workflow, which you
allude to above.

Just for the record, it was indeed a git pull which erased all changes in
my workspace.  It happened on 2014-12-08, as I was attempting to make my
first commit in git.  I had just performed git add for all changed files,
then did git pull to synchronise with savannah before doing the local
commit.  I still had open buffers in Emacs for all these files, 13 files
in all, which I saved, appending a suffix to each of their names.  It was
some tedious manual work and six days later before I actually pushed that
commit to savannah.

Since that time, whenever I have files in the staging area ready to
commit, and do a git pull, those files end up no longer being in the
staging area.

What a flexible tool git isn't!

> Granted, Git has a lot of spurious complication (the Git analogs of
> `cl-caadar'! this happens when a tool is work-in-progess, as all
> useful free software tools are in practice), ....

That's garbage by association, Stephen.  You're suggesting here that all
useful free software tools share git's over-complication, and that this
is therefore all right.  It's not.  Emacs, for example, was carefully and
masterfully architected from the start, with a clear vision.  git appears
to have been hacked together in a hurry with nobody with any taste in
charge.  As Antoine St. Exupéry is reported to have said, a design is
complete not when there's nothing left to add, but when there's nothing
left to remove.

> ...., but the problems Richard and Alan are encountering are soon
> solved by those who study a little bit, and establish some discipline
> in performing what they've learned.

Excuse me, but that is disparagingly patronising.  I have studied git a
LOT; I was forced to, merely to be able to use it at a most basic level.
Richard simply doesn't have the time (and we're talking about tens of
hours) to invest in getting up to speed with git.  There is no "soon"
about git learning, and the insinuation that I am undisciplined in my
use of VCSs is uncalled for.

> Richard and Alan, too, could very easily develop and make habitual a
> DVCS routine that allows them to continue the same programming workflow
> with a little extra typing that happens to differ from CVS.[2]  Instead
> they started a flamewar, and Richard has made explicit that he expects
> somebody else to do most of the work of adapting git to his
> specification.

Again you're muddying the waters, insinuating that we're both stuck in
the antediluvian CVS past.  Richard and I have both used bzr, relatively
free of problems, and I have used and still use Mercurial, which I like.
DVCSs, generically, are not the problem.

> There's nothing wrong with wanting your tools to be adapted to you, of
> course, but if you want to cooperate with others, sometimes you need
> to compromise with the shared tools.

More insinuations.  Although I have criticised git's many shortcomings,
I have never requested or suggested that other people adapt it to my
liking.  And nobody could fairly accuse me of not compromising with git.

-- 
Alan Mackenzie (Nuremberg, Germany).