Re: Stupid git!

[Alan Mackenzie <acm@muc.de>]

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