From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message, Date: Mon, 13 Apr 2015 21:06:54 +0000 Message-ID: <20150413210654.GB6324@acm.fritz.box> References: <83oan2l4pk.fsf@gnu.org> <5521B811.8070603@yandex.ru> <83d23hlmia.fsf@gnu.org> <20150407165131.GA2600@acm.fritz.box> <552486A4.2020803@yandex.ru> <5525D65C.8090303@yandex.ru> <83fv89g3dl.fsf@gnu.org> <87mw2he0d7.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1428959254 21704 80.91.229.3 (13 Apr 2015 21:07:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Apr 2015 21:07:34 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, rms@gnu.org, Dmitry Gutov To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 13 23:07:25 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YhlZg-0005vI-KX for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2015 23:07:20 +0200 Original-Received: from localhost ([::1]:53421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhlZf-0005cQ-Hj for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2015 17:07:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhlZQ-0005bx-5V for emacs-devel@gnu.org; Mon, 13 Apr 2015 17:07:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhlZK-0001fC-83 for emacs-devel@gnu.org; Mon, 13 Apr 2015 17:07:04 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:13993 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhlZJ-0001em-UR for emacs-devel@gnu.org; Mon, 13 Apr 2015 17:06:58 -0400 Original-Received: (qmail 40586 invoked by uid 3782); 13 Apr 2015 21:06:55 -0000 Original-Received: from acm.muc.de (p548A4102.dip0.t-ipconnect.de [84.138.65.2]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 13 Apr 2015 23:06:54 +0200 Original-Received: (qmail 7169 invoked by uid 1000); 13 Apr 2015 21:06:54 -0000 Content-Disposition: inline In-Reply-To: <87mw2he0d7.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185384 Archived-At: 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).