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 18:40:21 +0300 Message-ID: <8337r2r996.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1459698078 14738 80.91.229.3 (3 Apr 2016 15:41:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Apr 2016 15:41:18 +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 17:41:17 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 1amk9L-0002kX-Si for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 17:41:16 +0200 Original-Received: from localhost ([::1]:53976 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amk9L-0003wF-8S for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 11:41:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amk90-0003s8-V1 for emacs-devel@gnu.org; Sun, 03 Apr 2016 11:40:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amk8z-0001oc-V2 for emacs-devel@gnu.org; Sun, 03 Apr 2016 11:40:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55228) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amk8w-0001oH-3Z; Sun, 03 Apr 2016 11:40:50 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3368 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1amk8v-0003WO-8X; Sun, 03 Apr 2016 11:40:49 -0400 In-reply-to: <8760vyemy0.fsf@acer.localhost.com> (message from Ingo Lohmar on Sun, 03 Apr 2016 17:23:03 +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:202633 Archived-At: > From: Ingo Lohmar > Cc: acm@muc.de, emacs-devel@gnu.org, kaushal.modi@gmail.com > Date: Sun, 03 Apr 2016 17:23:03 +0200 > > On Sun, Apr 03 2016 18:01 (+0300), Eli Zaretskii wrote: > > >> From: Ingo Lohmar > >> Date: Sun, 03 Apr 2016 14:30:27 +0200 > >> Cc: Emacs developers , > >> Kaushal Modi > >> > >> Single caveat: Do NOT start a merge when you have uncommited changes. > >> If you want, do 'git stash' first to recover them later. > > > > I disagree with this caveat. There's no reason to frighten people > > like that, as doing such merges will work most of the time. > > > > This is not about frightening people; to reiterate, this is a prominent > warning on the git merge man page --- I will not tell people it's ok > when the official documentation discourages it. 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. > Also, in my opinion it is conceptually a bad practice to start git > operations that affect the commit graph (such as merge) from an > unclean state. 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. > >> In this case, you have to learn about rebase, as in 'git rebase > >> origin/master'. > > > > "git rebase" is a bad idea when merging a long-lived feature branch, > > so please don't advise this to users who are evidently not Git > > experts. > > It is my understanding (and I made it clear that it was partly > guesswork) that Alan asked precisely for that functionality. I am not > sufficiently patronizing to tell intelligent people they are not ready > for something when they explicitly ask for it. :) You may wish re-reading some of Alan's past messages about his adventures with Git, to get a better idea about that.