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: Stupid git! Date: Sat, 12 Sep 2015 12:29:00 +0000 Message-ID: <20150912122900.GC2322@acm.fritz.box> References: <20150912101514.GA2322@acm.fritz.box> <55F40103.9080300@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1442060896 26936 80.91.229.3 (12 Sep 2015 12:28:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2015 12:28:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 12 14:28:08 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 1ZajuY-0002UD-9v for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2015 14:28:06 +0200 Original-Received: from localhost ([::1]:60641 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZajuX-0001TI-KF for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2015 08:28:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZajuK-0001T1-IP for emacs-devel@gnu.org; Sat, 12 Sep 2015 08:27:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZajuH-0007N2-Bo for emacs-devel@gnu.org; Sat, 12 Sep 2015 08:27:52 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:39352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZajuH-0007Mv-2n for emacs-devel@gnu.org; Sat, 12 Sep 2015 08:27:49 -0400 Original-Received: (qmail 92107 invoked by uid 3782); 12 Sep 2015 12:27:47 -0000 Original-Received: from acm.muc.de (p548A4594.dip0.t-ipconnect.de [84.138.69.148]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Sep 2015 14:27:46 +0200 Original-Received: (qmail 3575 invoked by uid 1000); 12 Sep 2015 12:29:00 -0000 Content-Disposition: inline In-Reply-To: <55F40103.9080300@yandex.ru> User-Agent: Mutt/1.5.23 (2014-03-12) 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:189861 Archived-At: Hello, Dmitry. On Sat, Sep 12, 2015 at 01:40:03PM +0300, Dmitry Gutov wrote: > On 09/12/2015 01:15 PM, Alan Mackenzie wrote: > > Having "staged" a change with `git add', I then tried to commit it with > > `git commit'. Somebody else had got in before me, so I had to pull > > their changes first - fair enough. > I don't get it. This sounds like the commit failed because someone has > pushed to master in the upstream repo first. Which obviously can't > happen because git doesn't have "bound branches" a la Bazaar. Sorry, I got confused. I thought I'd only half-committed the change (with `git add'), whereas I had in fact fully committed it. > But in general, you either 'git stage' and then 'git pull', or 'git > add', 'git commit' (!), and then either rebase or merge upstream. It's when first doing `git add', then `git pull' when I've lost changes before. > The fact that git allows pulling after 'git add' sounds like a bug to > me, but apparently it sort-of fine because you can do two-way merge, or > even abort the merge and return to the previous state. I've always done a final `git pull' before committing in the past, so as to avoid merges as far as possible. This is what has lost me changes. > > So I did `git pull'. I was then dumped into an editing session for a > > merge operation for .../test/automated/file-notify-tests.el. Eh? I've > > never touched this file in my life, and didn't even know it existed. So > > why is a merge necessary/why has a merge been (half-)done? Why didn't > > git pull simply merge the changes to this file into my repository and > > working directory? > Was there a conflict in this file, or not? If yes, you can see the > diverging changes. If not, then you don't need to merge it at all, just > resolve the conflicts. There were no conflicts, just the other contributer's changes that my `git pull' had pulled. > How were you even "dumped into an editing session"? What tool did that? git did, on my `git pull'. I think I can see what happened now - when there's a pending push already committed, git refuses to merge in even unrelated changes. Instead it merged the file in my working directory, leaving me to commit it. I'm not sure why. > > So I aborted this merge operation, in order to see what it's doing > > first. git has kindly discarded my (staged) change, leaving no record > > of its existence - good job I've still got a copy of the changed file in > > Emacs. > That might be a good subject for a bug report. That was my mistake: the commit had already been fully committed, not just half committed like I'd thought. > > How do I see what changes are in file-notify-tests.el, which is in the > > staging area? I would have thought some variety of `git diff' ought to > > do the trick, but how to do this is not made obvious in the fine manual > > for `git diff'. > git diff --cached (or --staged, it's a synonym) OK, thanks! > It's pretty easy to find out in the output of 'man git diff' on my > system. Not sure what manual you've been reading. It's not easy at all - I've got the collected edition of git man pages in an info file. The one for git diff is 1036 lines long. I tried searching for "index" and "staging", to no avail - I think I stopped the search after getting beyond the OPTIONS section. Now that I know that "--cached" is the answer, that is specified in the EXAMPLES section. "--staged" doesn't appear at all. Anyhow, I used --staged to look at the file. Thanks! -- Alan Mackenzie (Nuremberg, Germany).