Re: Missing changes in merges from emacs-25 to master

[Eli Zaretskii]

> From: David Engster <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Fri, 25 Mar 2016 12:38:15 +0100
> 
> >> When you merge a branch, you have to merge all of it. But when they are
> >> marked as 'skipped', they will be merged with strategy "ours",
> >> effectively ignoring their content.
> >
> > What does "their content" include, exactly?
> 
> The patch.
> 
> The merge-strategy "ours" means: merge the commit, but take "our"
> version of everything that would be changed by it. The commit is seen as
> merged afterwards, but without applying the patch it includes.

I'm not sure I understand the meaning of this.  Let me ask a more
specific question, about the particular commit that bothers me.  Once
again, it is this commit from the emacs-25 branch:

  commit ad879b7f7e049160c45361fe8a12580801ba035b
  Author: K. Handa <address@hidden>
  Date:   Thu Jan 14 21:48:44 2016 +0900

      Backport:fix previous change of src/ftfont.c (ftfont_shape_by_flt)

      * src/ftfont.c (ftfont_shape_by_flt): Fix previous change.  Access the
      second glyph only when there are enough glyphs.

      (cherry picked from commit 9835757013569673854b692ccbb58bfb3c3ed1f7)

It was originally made on master, as 9835757, then cherry-picked to
emacs-25 as above and committed there as ad879b, and then merged back
to master in 3005605, with this log message:

  commit 3005605776955593e0b416de9e1ebf158114343e
  Merge: cb4e054 ad879b7
  Author: Paul Eggert <address@hidden>
  Date:   Sat Jan 30 11:43:27 2016 -0800

      ; Merge from origin/emacs-25

      The following commits were skipped:

      ad879b7 Backport:fix previous change of src/ftfont.c (ftfont_shape_by_flt)
      4a3db0f support rendering of wider range of combinging characters by 
ftfont

After all this, what would you expect "git annotate" to show on the
master branch as the commit that introduced the affected source lines?
Shouldn't it show the original commit, i.e. 9835757?  Because it
doesn't show that, it shows ad879b7 instead.  If that's expected
behavior, then I _really_ don't understand what "skip" means here,
since it sounds like it didn't use the "ours" strategy, according to
your definition.  What am I missing?

> > With Bazaar, there was a clear mainline, displaying which these
> > commits wouldn't appear at all. We don't have that with Git, so the
> > analogy doesn't really help.
> 
> Bazaar didn't display *any* commits from merged branches by default,
> whether they were "skipped" or not.

Of course: those commits were on other branches, so they are
irrelevant for the mainline.  What Bazaar would show is the single
merge-commit, which (with Bazaar) "represents" the commits on the
merged branch.

> So again: gitmerge does that same as bzrmerge did. That we don't
> invest the effort to keep our mainline on the "left side" is another
> matter.

I didn't yet voice any complaints about what gitmerge does, I'm just
saying that something seems wrong in the DAG.  Whether it was gitmerge
that produced that remains to be seen; for now, we cannot even agree
on what we actually see there, and whether it constitutes a problem ;-)