all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
Subject: Re: Stupid git!
Date: Sat, 12 Sep 2015 13:40:03 +0300	[thread overview]
Message-ID: <55F40103.9080300@yandex.ru> (raw)
In-Reply-To: <20150912101514.GA2322@acm.fritz.box>

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.

But in general, you either 'git stage' and then 'git pull', or 'git 
add', 'git commit' (!), and then either rebase or merge upstream.

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.

> 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.

How were you even "dumped into an editing session"? What tool did that?

> 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.

> 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)

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.



  parent reply	other threads:[~2015-09-12 10:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-12 10:15 Stupid git! Alan Mackenzie
2015-09-12 10:21 ` Alan Mackenzie
2015-09-12 10:40 ` Dmitry Gutov [this message]
2015-09-12 12:29   ` Alan Mackenzie
2015-09-12 12:34     ` David Kastrup
2015-09-12 12:59       ` Alan Mackenzie
2015-09-12 20:14     ` Dmitry Gutov
2015-09-14 10:09     ` Steinar Bang
2015-09-12 20:37   ` Stefan Monnier
2015-09-12 10:40 ` David Kastrup
2015-09-12 10:53   ` Dmitry Gutov
2015-09-12 12:52   ` Alan Mackenzie
2015-09-12 11:45 ` Giuseppe Scrivano
2015-09-12 13:02   ` Alan Mackenzie
2015-09-12 14:12     ` Andreas Schwab
2015-09-12 15:16     ` Eli Zaretskii
2015-09-12 20:36       ` Alan Mackenzie
2015-09-12 20:43         ` Dmitry Gutov
2015-09-12 21:51           ` Alan Mackenzie
2015-09-13  6:22             ` Sven Axelsson
2015-09-14 10:21               ` Alan Mackenzie
2015-09-14 10:29                 ` David Kastrup
2015-09-14 12:19                   ` Eli Zaretskii
2015-09-14 12:28                     ` David Kastrup
2015-09-14 12:37                       ` Eli Zaretskii
2015-09-14 12:47                         ` David Kastrup
2015-09-14 13:38                           ` Eli Zaretskii
2015-09-14 13:44                             ` David Kastrup
2015-09-14 12:38                   ` Stefan Monnier
2015-09-13  6:49             ` Eli Zaretskii
2015-09-14 10:49               ` Alan Mackenzie
2015-09-15  0:24                 ` Stephen J. Turnbull
2015-09-13 20:28             ` Dmitry Gutov
2015-09-14  3:11               ` Stephen J. Turnbull
2015-09-14 13:47                 ` Dmitry Gutov
2015-09-14 11:09               ` Alan Mackenzie
2015-09-14 12:22                 ` Eli Zaretskii
2015-09-14 13:42                 ` Dmitry Gutov
2015-09-14 17:05                   ` Steinar Bang
2015-09-14 10:37             ` Steinar Bang
2015-09-13  6:42         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55F40103.9080300@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.