From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Stupid git! Date: Mon, 14 Sep 2015 15:44:25 +0200 Message-ID: <87twqxund2.fsf@fencepost.gnu.org> References: <20150912101514.GA2322@acm.fritz.box> <877fnvn9nh.fsf@foo.bar.baz> <20150912130255.GF2322@acm.fritz.box> <83egi3brbw.fsf@gnu.org> <20150912203658.GA3711@acm.fritz.box> <55F48E7F.40602@yandex.ru> <20150912215114.GB3711@acm.fritz.box> <20150914102158.GA3208@acm.fritz.box> <877fntway6.fsf@fencepost.gnu.org> <83d1xl9osa.fsf@gnu.org> <8737yhw5gp.fsf@fencepost.gnu.org> <83a8sp9nxr.fsf@gnu.org> <87y4g9uq0c.fsf@fencepost.gnu.org> <834mix9l3s.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442239555 30905 80.91.229.3 (14 Sep 2015 14:05:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 14:05:55 +0000 (UTC) Cc: acm@muc.de, sven.axelsson@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 16:05:54 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 1ZbUOI-0000rN-2L for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 16:05:54 +0200 Original-Received: from localhost ([::1]:41094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbUOG-0000ct-PS for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 10:05:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbUGS-0003ak-In for emacs-devel@gnu.org; Mon, 14 Sep 2015 09:57:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbUGH-0003Me-Se for emacs-devel@gnu.org; Mon, 14 Sep 2015 09:57:48 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbUG2-0002fQ-8V; Mon, 14 Sep 2015 09:57:22 -0400 Original-Received: from localhost ([127.0.0.1]:46697 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZbU3X-0000T6-0R; Mon, 14 Sep 2015 09:44:27 -0400 Original-Received: by lola (Postfix, from userid 1000) id 9A68AE0897; Mon, 14 Sep 2015 15:44:25 +0200 (CEST) In-Reply-To: <834mix9l3s.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Sep 2015 16:38:47 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:189944 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: acm@muc.de, sven.axelsson@gmail.com, emacs-devel@gnu.org >> Date: Mon, 14 Sep 2015 14:47:15 +0200 >> >> >> >> Pulling is not a really good thing to do if you have uncommitted work. >> >> > >> >> > I'm doing it all the time, and have yet to report a single problem. >> >> > >> >> > It's the simplest way of minimizing the probability of spurious >> >> > merges, when someone else pushes before you. >> >> >> >> Nope. The simplest way is to git fetch rather than git pull. >> > >> > How is using 2 commands instead of one, and learning an additional >> > command, simpler? >> >> The "simplest way of minimizing the probability of spurious merges" is >> not to execute commands doing possibly unintended merges. > > If your recipe would have been "don't use pull", it would have been > simpler. But that's not what it says, it says "use fetch and merge > instead", which is definitely not simpler. > >> If you insist on only ever using git pull, it also has an option >> --ff-only which will refuse to do anything non-trivial. > > At the cost of having to learn the option. Not simpler. > >> >> > If you commit then pull, and someone else pushed in between, you >> >> > will get that "merged branch master" thing. >> >> >> >> It that's not what you want, git pull -r will rebase just fine. >> > >> > We've concluded long ago that "pull --rebase" is trouble when you >> > merge from and to feature branches, so I'm trying to stay away of that >> > path. >> >> That's ridiculous. What we have concluded is that setting --rebase as a >> default was not likely a good idea because of feature branches. But it >> is quite absurd not to use the option for those cases where you indeed >> want a rebase instead of a merge commit. > > It's not absurd when you take muscle memory into consideration. We > are talking here about routine operations (since you don't know in > advance whether a pull will cause conflicts or a need to merge), not > about an option to be used in specific rare circumstances. The simplest option taking muscle memory into account is throwing the computer against the wall. If you are not interested in actually achieving the objective ("minimizing the probability of spurious merges"), that seems by far the simplest action. I just don't see the point in discussing the simplest action you can take without actually achieving the objective at the same point of time. -- David Kastrup