Re: Stupid git!

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Alan,

On 09/14/2015 02:09 PM, Alan Mackenzie wrote:

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

Indeed, I don't usually see that. Hence my question about --no-commit in 
your gitconfig.

But others' suggestion that it might be because of 'git add' beforehand 
is also plausible. I never do that, because it makes little sense.

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

I any case, a merge with maybe just one tiny conflict, looks similar to 
this if there are also non-conflicting changes in it: it shows you 
staged changes from files *you* didn't modify.

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

Kinda both.

It means that you shouldn't 'git add' any changes that you've worked on 
just now, before committing. Leave them for a following, non-merge commit.

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

Apparently, you will be able to see the log entries for the commits 
you're merging, after you conclude the merge, and so the current branch 
includes them. Makes sense, doesn't it?

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

I agree.