Re: Stupid git!

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Sep 13, 2015 at 11:28:25PM +0300, Dmitry Gutov wrote:
> On 09/13/2015 12:51 AM, Alan Mackenzie wrote:

> > On branch master
> > Your branch and 'origin/master' have diverged,
> > and have 1 and 1 different commit each, respectively.
> >    (use "git pull" to merge the remote branch into yours)
> > All conflicts fixed but you are still merging.
> >    (use "git commit" to conclude merge)

> I think what Git says here is pretty transparent: commit to conclude the 
> merge.

What confused me is that git aborted the merge despite there being no
conflicts (i.e., nothing requiring the use of an editor to resolve).
git could quite easily have just completed the merge itself instead of
aborting it then requiring me to take mechanical actions to complete it.

> > :-).  OK, but the immediate problem is that _I_ didn't modify
> > file-notify-tests.el.  Somebody else did, and git put his changes into
> > my working directory and `git add'ed it.

> Yes, it did. Have you done any non-trivial merges before? That's how 
> they usually look.

No, I've never done a non-trivial merge in git.  This one presumably
must count as a trivial merge.

> The merge commit shouldn't, generally, include any non-mergy changes, so 
> you're not expected to stage any of the files you've been working on, 
> before committing.

I take it that by "shouldn't .. include include .. non-mergy changes"
you mean that when initiating a merge commit, git won't include any
non-merge changes in the commit.  (The alternative interpretation is
that in a merge commit, the user shouldn't include any other changes.)

> > I don't have the log entry for
> > this change.  So am I supposed to just commit this, with my own log
> > entry?

> The log entry should describe the merge (you could leave the default 
> message there, unless it's necessary to add more info).

I did actually have this log entry, but `git log' didn't display it.
The flag --all was needed for that.

> > I don't really understand what "you are still merging" is supposed to
> > mean.  How do I get out of the "merging" state cleanly, without
> > commiting somebody else's changes?

> The merge commit is *supposed to* include all the changes that have been 
> merged in. If you take it upon yourself to remove those changes from the 
> staging area, as a result Emacs won't include them, and it won't be 
> obvious to most of the people who read emacs-diffs, and then someone 
> will have to find out the hard way that something's missing.

OK, I've got it now.  For some reason, git choses to abort the merge,
despite there being no conflicts between the changes from upstream and
the changes I've committed locally - indeed, to complete the merge is a
fully mechanical action, `git commit'.  This seeming illogicality is
what confused me in the first place.

-- 
Alan Mackenzie (Nuremberg, Germany).