On Wed, Feb 7, 2018 at 4:29 AM, Mark Brown broonie@kernel.org wrote:
I'm frankly a little bit confused about what went wrong here, usually git does manage to elide empty merges - for example, if I ask git to merge four branches two of which are already merged:
Yes, so git does elide truly trivial merges, but the git triviality test is actually not "have all the commits been merged elsewhere", but "are all the branches completely just subsets in history of each other".
So a single extra merge commit that exists in one branch but not the others will defeat that, and then you get a merge of a merge etc. That's something we saw early on, when people would do daily back-merges - even if there was no extra work in the development branch, the previous back-merge *itself* would mean that the merge wouldn't fast-forward to the upstream code, but would just do another merge, because upstream wasn't a full superset of the development branch due to the previous back-merge that wasn't upstream.
But in this case, the issue doesn't seem to be a previous back-merge, but simply that the commits ion question had been merged up-stream - but they weren't in your development branch, so when your development branch does a merge, to *that* branch it looks like new commits, even if it isn't anythign new or interesting to *me*, because I got those commits from Takashi's pull two weeks ago.
This new pull request looks better, I'll look at it next.
Linus