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

[Eli Zaretskii <eliz@gnu.org>]

> From: David Engster <deng@randomsample.de>
> Cc: johnw@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 25 Mar 2016 17:00:45 +0100
> 
> > 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?
> 
> Well, the cherry-picked commit ad879b7 is now in master's history. The
> patch of that diff shows that it changes those lines. That we chose to
> ignore the patch can only be seen by looking at the merge commit
> 300560577, which references the same 'tree' as the previous merge
> 'cb4e054e', meaning they both reference they same set of files:
> 
>   > git cat-file 300560577 -p                            
>     tree ae2bec4f10425bd61e2a90563edc178d382bb4b8
>     [...]
> 
>   > git cat-file cb4e054e41c -p
>     tree ae2bec4f10425bd61e2a90563edc178d382bb4b8
> 
> My best guess is that 'git annotate' does not incorporate that
> information, but I'm not familiar with the inner workings of that
> command. Maybe no one bothered to implement it, or maybe it would make
> annotation even slower.

So I guess the fact that a commit was skipped during a merge is
something that is so hard to see that perhaps the entire issue of
skipping is moot with Git, and we shouldn't be bothered by it.

> >> > 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.
> 
> Those commits were made part of mainline's history

Not in Bazaar's philosophy.  They are part of the DAG, but not of the
branch's mainline.

> > What Bazaar would show is the single merge-commit, which (with Bazaar)
> > "represents" the commits on the merged branch.
> 
> I forgot how it worked in Bazaar. Did a merge commit hold the full patch
> information of all merged commits?

Yes.

> I can at least assure you that the patches from those commits are
> ignored.

I believe you.  It's just strange and confusing that so many Git
commands show information that indicates the opposite, and the truth
is only shown by looking at the low-level objects and comparing
hashes.