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: Understanding a recent commit in emacs-25 branch [ed19f2] Date: Sun, 03 Apr 2016 19:19:26 +0300 Message-ID: <83zitapsvl.fsf@gnu.org> References: <20160403111708.GA3537@acm.fritz.box> <87lh4uex9h.fsf@acer.localhost.com> <20160403121458.GC3537@acm.fritz.box> <87bn5qeuxo.fsf@acer.localhost.com> <838u0urb1w.fsf@gnu.org> <8760vyemy0.fsf@acer.localhost.com> <8337r2r996.fsf@gnu.org> <8737r2el7d.fsf@acer.localhost.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1459700415 16901 80.91.229.3 (3 Apr 2016 16:20:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Apr 2016 16:20:15 +0000 (UTC) Cc: acm@muc.de, kaushal.modi@gmail.com, emacs-devel@gnu.org To: Ingo Lohmar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 03 18:20:09 2016 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 1amkky-0003pn-4y for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 18:20:08 +0200 Original-Received: from localhost ([::1]:54273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amkkx-0000l2-LT for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 12:20:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amkku-0000kP-55 for emacs-devel@gnu.org; Sun, 03 Apr 2016 12:20:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amkks-0001Mr-Uv for emacs-devel@gnu.org; Sun, 03 Apr 2016 12:20:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amkkn-0001KA-Qv; Sun, 03 Apr 2016 12:19:57 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3409 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1amkkk-0003R1-MH; Sun, 03 Apr 2016 12:19:57 -0400 In-reply-to: <8737r2el7d.fsf@acer.localhost.com> (message from Ingo Lohmar on Sun, 03 Apr 2016 18:00:38 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:202636 Archived-At: > From: Ingo Lohmar > Cc: acm@muc.de, emacs-devel@gnu.org, kaushal.modi@gmail.com > Date: Sun, 03 Apr 2016 18:00:38 +0200 > > On Sun, Apr 03 2016 18:40 (+0300), Eli Zaretskii wrote: > > I think your documentation might be outdated. Here's what the "git > > pull" man page I have says: > > > > In Git 1.7.0 or later, to cancel a conflicting merge, use git reset > > --merge. Warning: In older versions of Git, running git pull with > > uncommitted changes is discouraged: while possible, it leaves you in a > > state that may be hard to back out of in the case of a conflict. > > > > If any of the remote changes overlap with local uncommitted changes, > > the merge will be automatically cancelled and the work tree > > untouched. It is generally best to get any local changes in working > > order before pulling or stash them away with git-stash(1). > > > > This is with Git 2.8.0. > > > > IOW, for a recent enough Git, they _recommend_ stashing, but no longer > > _warn_ about merging in this situation. Which is exactly my > > experience. > > For the sake of completeness, my 'git merge' man page for 2.8.0.rc3 says > (in the DESCRIPTION section): > > Warning: Running git merge with non-trivial uncommitted changes > is discouraged: while possible, it may leave you in a state that > is hard to back out of in the case of a conflict. But we were talking about "git pull", not about merge. > > I agree that it's preferable to have a clean repo, but in practice it > > doesn't always work to have it. Being able to pull when you have > > uncommitted changes is an important feature; a VCS that doesn't > > support it is IMO severely broken, because it will get in the way. > > We'll just have to disagree about the "severely broken" part. Yes, let's do that.