From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Understanding a recent commit in emacs-25 branch [ed19f2] Date: Sun, 3 Apr 2016 12:14:58 +0000 Message-ID: <20160403121458.GC3537@acm.fritz.box> References: <20160403111708.GA3537@acm.fritz.box> <87lh4uex9h.fsf@acer.localhost.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1459685553 29393 80.91.229.3 (3 Apr 2016 12:12:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Apr 2016 12:12:33 +0000 (UTC) Cc: Emacs developers , Kaushal Modi To: Ingo Lohmar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 03 14:12:23 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 1amgtD-0007ED-DJ for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 14:12:23 +0200 Original-Received: from localhost ([::1]:53222 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amgt9-00056S-Jo for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 08:12:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amgsw-00056L-J4 for emacs-devel@gnu.org; Sun, 03 Apr 2016 08:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amgst-0003gV-Cf for emacs-devel@gnu.org; Sun, 03 Apr 2016 08:12:06 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:36897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amgst-0003gI-3L for emacs-devel@gnu.org; Sun, 03 Apr 2016 08:12:03 -0400 Original-Received: (qmail 9313 invoked by uid 3782); 3 Apr 2016 12:12:02 -0000 Original-Received: from acm.muc.de (p548A58C8.dip0.t-ipconnect.de [84.138.88.200]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 03 Apr 2016 14:12:00 +0200 Original-Received: (qmail 4769 invoked by uid 1000); 3 Apr 2016 12:14:58 -0000 Content-Disposition: inline In-Reply-To: <87lh4uex9h.fsf@acer.localhost.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.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:202618 Archived-At: Hello, Ingo. On Sun, Apr 03, 2016 at 01:40:10PM +0200, Ingo Lohmar wrote: > Hi Alan, > On Sun, Apr 03 2016 11:17 (+0000), Alan Mackenzie wrote: > > That massive commit happened because of git. I attempted a 'git pull' > > prior to making a (moderately small) commit. There was a one-letter > > typo in one of my existing files (which I think had been committed). > > Because of that, git failed to merge in all the stuff which it had just > > fetched from savannah, instead prompting me to do a manual merge, which > > I then did. > I think 'git pull' has been discussed on this list before. Others feel > differently about this issue, but I strongly advise anyone against using > 'git pull', and instead suggest you do 'git fetch' (maybe --all). > *After* seeing what has happened to the remote branches, you can decide > whether a merge or a rebase is in order. Or you spot an unwanted > discrepancy, and can fix it, instead of git telling you to manually > merge (although admittedly I do not quite follow that part). Is there a way of asking "if I attempt git merge, will there be any conflicts?"? It would be nice to find this out before one's working directory gets lots of uncommitted changes. Is there a way of recovering after doing git pull, when git has already written all the pulled changes to the working directory? Is there some way of saying git undo-partial-pull, leaving the working directory as it was before the pull, and cancelling the merge which git has started? > > It would also be nice if such "pseudo merges" could be handled locally, > > rather than being pushed back to the remote repository, causing > > confusion. > Please note that *all* commits and merges happen locally. The user can > only push changes back to the remote by an explicit action, with all > intended and unintended effects. Sorry, I wasn't very clear. What I meant was, is there a way of finishing the merge locally, then pushing real changes without the confusing "pseudo-merge" escaping upstream with them? When I did git pull, there were, let's say, 20 commits. 19 of these could have been moved directly into my local repository; only one had a conflict. It would be nice to be able to fix the local repo, so that the "pseudo-merge" of these 19 blameless commits remains a purely local affair, and doesn't get pushed upstream. -- Alan Mackenzie (Nuremberg, Germany).