From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.devel Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS Date: Fri, 19 Dec 2014 09:09:03 +0100 Organization: Probably a good idea Message-ID: References: <20141211155740.11916.1584@vcs.savannah.gnu.org> <83a92trlgs.fsf@gnu.org> <87oar81jlp.fsf@lifelogs.com> <87bnn7rkcq.fsf@engster.org> <877fxvri96.fsf@engster.org> <87zjarznzs.fsf@lifelogs.com> <87sigjpri2.fsf@engster.org> <838uib60jv.fsf@gnu.org> <87mw6rpc6l.fsf@engster.org> <83sigj48z5.fsf@gnu.org> <874mszp2i7.fsf@engster.org> <83iohe43hu.fsf@gnu.org> <87vbldoqp2.fsf@engster.org> <83a92py3p3.fsf@gnu.org> <87mw6oodep.fsf@engster.org> <83lhm7wfd4.fsf@gnu.org> <87egrynhcd.fsf@engster.org> <87wq5pd0ap.fsf@uwakimon.sk.tsukuba.ac.jp> <83fvcdufv9.fsf@gnu.org> <87r3vwk9tr.fsf@dod.no> <83lhm4u1y3.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418976584 21597 80.91.229.3 (19 Dec 2014 08:09:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Dec 2014 08:09:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 19 09:09:38 2014 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 1Y1scz-0000Xx-7L for ged-emacs-devel@m.gmane.org; Fri, 19 Dec 2014 09:09:37 +0100 Original-Received: from localhost ([::1]:57181 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1scy-0007nj-JX for ged-emacs-devel@m.gmane.org; Fri, 19 Dec 2014 03:09:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1scp-0007mZ-6N for emacs-devel@gnu.org; Fri, 19 Dec 2014 03:09:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1scf-0005Nh-LY for emacs-devel@gnu.org; Fri, 19 Dec 2014 03:09:27 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:49294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1scf-0005NU-Dw for emacs-devel@gnu.org; Fri, 19 Dec 2014 03:09:17 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Y1scc-0000NE-MR for emacs-devel@gnu.org; Fri, 19 Dec 2014 09:09:14 +0100 Original-Received: from steria10.steria.no ([195.204.41.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Dec 2014 09:09:14 +0100 Original-Received: from sb by steria10.steria.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Dec 2014 09:09:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 33 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: steria10.steria.no Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (windows-nt) Cancel-Lock: sha1:nsLQDr+DYLaJjBtaRSIabcESd+g= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:180316 Archived-At: >>>>> Eli Zaretskii : > Not sure how what you suggest is different, in principle. Not different, just convenient. > Why does it matter if I examine the results of a merge before or after > I commit it? It's a local commit, and I can always go back if I need > to. Yes, of course. But magit's presentation of a staged, but yet uncommitted merge, is a very convenient and keyboard-only way of viewing the merge resuls (a compact representation of new files, for one thing, compared to a diff), and it's easy to fix conflicts, and revert files without leaving emacs. > But I see no reason to assume up front I'd need to back up, since we > are talking about a merge from the release branch, not from a > development branch. So I have all the reasons to believe the merge > will be uneventful, and there will be no conflicts most of the time. Not so much conflicts merging that way, but version number stuff always show up on the first merge, and sometimes later as well (it's good to check). And in emacs' case there has been the ChangeLog stuff (are they autogenerated and not committed these days?). > Which makes all the precautions like --no-ff and --no-commit > unnecessary, I think. I don't do it merging in to my own branches, but I always give published merges a final look-over in this way before pushing them (ie. merges _to_ master and release branches).