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

[David Engster <deng@randomsample.de>]

Eli Zaretskii writes:
>> 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.

Well, it's not *that* hard to see, but it usually requires to look at a
span of commits. In this case,

  git diff cb4e054e41c..300560577

will correctly produce nothing. But I agree it's unfortunate that you
cannot see this from the merge commit alone. But I'm not sure what you
mean with the entire issue being moot. How do you suggest we deal with
commits that shouldn't land in master?

-David