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: Thu, 18 Dec 2014 20:46:51 +0100 Organization: Probably a good idea Message-ID: <87vbl8kafo.fsf@dod.no> References: <20141211155740.11916.1584@vcs.savannah.gnu.org> <874mt14wrc.fsf@lifelogs.com> <83egs5rzlr.fsf@gnu.org> <877fxx2e6t.fsf@lifelogs.com> <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> <83h9wtufwl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418932049 11504 80.91.229.3 (18 Dec 2014 19:47:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 19:47:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 18 20:47:22 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 1Y1h2g-0006XS-1b for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 20:47:22 +0100 Original-Received: from localhost ([::1]:55561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1h2f-0004dl-G1 for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 14:47:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1h2V-0004de-Gg for emacs-devel@gnu.org; Thu, 18 Dec 2014 14:47:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1h2P-00068t-Iu for emacs-devel@gnu.org; Thu, 18 Dec 2014 14:47:11 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:36812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1h2P-00068i-CG for emacs-devel@gnu.org; Thu, 18 Dec 2014 14:47:05 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Y1h2N-0006SZ-85 for emacs-devel@gnu.org; Thu, 18 Dec 2014 20:47:03 +0100 Original-Received: from cm-84.208.248.210.getinternet.no ([84.208.248.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Dec 2014 20:47:03 +0100 Original-Received: from sb by cm-84.208.248.210.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Dec 2014 20:47:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 29 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.208.248.210.getinternet.no Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:B6Yragd0E5EE9r0Hc1ISgIkE6R4= 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:180288 Archived-At: >>>>> Eli Zaretskii : > But if we follow Stefan and stop worrying about the linearity of > mainline, then just "git pull" followed by another push is enough, > right? Yes. > Again, if we don't care about the mainline being linear, this > spaghetti is nothing to worry about, right? It's just a "normal" Git > DAG, right? Yes. > What really worries me about all this is that I _know_ some of the > more-or-less veteran contributors do have long-living branches, where > they do all their work, and from where they merge to master before > pushing. For those people, using "pull --rebase" might be trouble > waiting to happen at the most inopportune moment. Indeed,... unless you can break them of the habit of merging master into the feature branch before merging with master...? If they always merge from the feature branch into master and then push, they will be safe. They can merge back from master after they have successfully pushed master. But the safest will always be not to worry about the linearity of the mainline.