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

[...]

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

As you well know, Bazaar had a data model which was much more amenable
for annotating a file, so I guess it could deal with this issue
correctly (I haven't checked, though).

>> > 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, so how can they
possibly be "irrelevant"? It's just that Bazaar had the default to only
show mainline (which also confused plenty of people).

> 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? In any case, that's now the case for
Git: a merge commit is a normal commit, simply with more than one
parent.

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

I can at least assure you that the patches from those commits are
ignored. And I would claim that it worked essentially the same during
the Bazaar days. Just fire up 'gitk' and look at old merges from
emacs-24 into master; you'll find plenty of backported commits in the
merged branches, and bzrmerge dealt with it the same way (with the
exception that it did the whole merge in one go, while gitmerge does
separate merges).

-David