From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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: Sun, 05 Apr 2015 23:07:03 +0300 Message-ID: <83oan2l4pk.fsf@gnu.org> References: <20150405124321.362.95112@vcs.savannah.gnu.org> <552130FE.1010101@yandex.ru> <83mw2mn2no.fsf@gnu.org> <5521359D.2000509@yandex.ru> <83fv8emvgq.fsf@gnu.org> <55219139.8040507@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428264452 27136 80.91.229.3 (5 Apr 2015 20:07:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 20:07:32 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 05 22:07:23 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 1YeqpF-00076j-Au for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 22:07:21 +0200 Original-Received: from localhost ([::1]:37479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeqpE-0003Z7-NR for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 16:07:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yeqp0-0003Yr-0G for emacs-devel@gnu.org; Sun, 05 Apr 2015 16:07:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yeqov-0006IT-Th for emacs-devel@gnu.org; Sun, 05 Apr 2015 16:07:05 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:40551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yeqov-0006IG-Lo; Sun, 05 Apr 2015 16:07:01 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NMC00100NGN4O00@a-mtaout23.012.net.il>; Sun, 05 Apr 2015 23:07:00 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMC001RLNVN2E40@a-mtaout23.012.net.il>; Sun, 05 Apr 2015 23:07:00 +0300 (IDT) In-reply-to: <55219139.8040507@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:184978 Archived-At: > Date: Sun, 05 Apr 2015 22:47:05 +0300 > From: Dmitry Gutov > CC: rms@gnu.org, emacs-devel@gnu.org > > On 04/05/2015 06:43 PM, Eli Zaretskii wrote: > > >> 1) Forget the "push automatically after commit" nonsense > > > > The discussion is waaaay beyond that, so this is no longer relevant. > > That's not my impression from the last sentence in > http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00156.html Wrong impression. > > not very relevant > > to the issue at hand, which had to do with user confusion more than > > with anything else. > > Hence the item 2 below. That item is a dead end in practice, and is too harsh even if it were practical. > > And if we think double-checking each commit before pushing is a must, > > we should make VC support that seamlessly. After all, all Richard > > used was VC. > > We can come up with a more automatic solution, but even now it's > entirely doable using VC: `C-x v L' to open the log buffer, and when in > it, `C-m' to read the commit message, `d' to see the corresponding diff. You are missing the point: I meant "C-x v v", not some other command available with VC. It's "C-x v v" that got Richard in trouble in the first place, by trying to commit a single file in the middle of a failed merge. > Editing the already-created commits is more complicated, but I think > there was some advice on that subject too, in the humongous thread. It's also on the Wiki. > >> 2) People who don't know how to do that, and are unwilling to learn, or > >> who aren't confident in their results anyway should post patches to the > >> mailing list. > > > > I disagree. We should let people who want to use a CVS-like workflow > > do that. It's possible if done correctly. > > I'm not saying it's not possible, but a wrong commit message is extra > work for someone else who will have to correct it. It'll become more so > when the change log files are auto-generated. Which is why it is important to help those users find the right procedures they can safely follow. > > The previous instructions > > for that were sub-optimal, but I think they are now much more clear, > > accurate, and concise to allow using that workflow safely. > > It's better, but I think recommending `git diff origin/master' as the > first option is suboptimal, because it ignores the commit messages, > which we do want to look right. I don't mind switching the order. I myself use "git show". It's just that most others suggested "git diff", and its syntax is a bit simpler when more than one commit is involved. > > I see no reasons for being this harsh just because some contributors > > don't yet master Git enough to use it like we think they should. > > The workflow details aside, I think a committer should be motivated > enough to examine the result of their work before pushing. And if they > don't know how, learn that on their own. I don't think there's lack of motivation in this case. > But not everyone has to be an Emacs committer. That's not harsh: people > can have better priorities in life. Applied to veteran Emacs developers, it _is_ harsh, at least IMO. > >> Had Richard started with that, a lot of time would've been saved, on > >> many ends. > > > > Time spent helping someone is time well spent, at least as long as > > it's my time. > > Cue the "teach a man how to fish" proverb. It seems to me that the > result is only one fish on Richard's table, and one that was pretty > haphazardly prepared. We all need help from time to time. I see no reason to tell people they goofed too many times, especially if they already know that.