From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: master has switched from Automake to GNU Make Date: Fri, 24 Mar 2017 18:35:08 -0500 Message-ID: <86inmyp7tf.fsf@stephe-leake.org> References: <58CB9F6B.5080806@gmx.at> <83h92sz2j9.fsf@gnu.org> <58CBAEB7.5030601@gmx.at> <58CBBC6C.8000104@gmx.at> <58D380FF.1070103@gmx.at> <58D3C84E.5080808@gmx.at> <58D4E0D6.2070101@gmx.at> <86r31mlrj1.fsf@molnjunk.nocrew.org> <58D56B33.9050408@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490398531 14006 195.159.176.226 (24 Mar 2017 23:35:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Mar 2017 23:35:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.91 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 25 00:35:26 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crYjp-0002i0-9u for ged-emacs-devel@m.gmane.org; Sat, 25 Mar 2017 00:35:21 +0100 Original-Received: from localhost ([::1]:35304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crYjv-0007vF-4e for ged-emacs-devel@m.gmane.org; Fri, 24 Mar 2017 19:35:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crYjp-0007v1-5o for emacs-devel@gnu.org; Fri, 24 Mar 2017 19:35:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1crYjk-0004b8-7y for emacs-devel@gnu.org; Fri, 24 Mar 2017 19:35:21 -0400 Original-Received: from smtp145.dfw.emailsrvr.com ([67.192.241.145]:48763) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1crYjk-0004aX-2e for emacs-devel@gnu.org; Fri, 24 Mar 2017 19:35:16 -0400 Original-Received: from smtp23.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id ED54BE034E for ; Fri, 24 Mar 2017 19:35:13 -0400 (EDT) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp23.relay.dfw1a.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 772B3E010A for ; Fri, 24 Mar 2017 19:35:13 -0400 (EDT) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 (76-218-37-33.lightspeed.kscymo.sbcglobal.net [76.218.37.33]) (using TLSv1.2 with cipher AES128-GCM-SHA256) by 0.0.0.0:587 (trex/5.7.12); Fri, 24 Mar 2017 19:35:13 -0400 In-Reply-To: <58D56B33.9050408@gmx.at> (martin rudalics's message of "Fri, 24 Mar 2017 19:53:39 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 67.192.241.145 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:213321 Archived-At: martin rudalics writes: > All this is about the final result of what a branch was supposed to > accomplish and I agree with you here. Ok. > My concerns were with what happens in the branch as long as it is not > final. Why throw away its history when pushing? Because it contains > silly code its author would be ashamed of? Yes, but I would phrase it "it contained a failed approach, so here's a better approach". Or, "the sequence of commits is too hard to follow, since it has false starts and back-tracking, so here's a cleaner sequence". One could argue that new approach should have yet another branch. Which is a good idea if you are not _really_ sure the second approach is better, or will work. Partly it depends on how closely people are cooperating on the branch. If it's two or more developers actively working on all the code, then pushing a totally new set of commits is a Bad Idea; the other developers will lose work (or time in recovering). But our presumed use case is one developer actively working on the code, and asking for reviews. In which case, a clean sequence of understandable commits is a big plus. -- -- Stephe