git: Can git realize that commits I have received from one remote are the same as those coming from a different remote?

Question

I am wondering why some behaviour using git occurs:

I forked a project on github to my own project on github. I then cloned my project to my computer. Some changes occured to the original project, so I told github to commit them using its fork queue. I do git pull on my computer to get these changes.

Now some more changes came to the original project but this time I added a remote branch to the original project on my computer. When I do a git fetch on it and then a git merge to my local branch I get a conflict.

I can't see why it would do this as I am almost up to date and just need the last few commits applied? Can git not tell that I already have the first set of commits, because I got them indirectly via my own github project fork?

Answer 1

Those aren't the same commits. They were cherry-picked. The easiest way to get it working is to rebase your local branch over the remote changes instead of trying to merge them.

The rebase will note that the upstream changes are the same and then drop them.

Answer 2

The GitHub Fork Queue is fundamentally broken and under no circumstances should it ever be used. The Fork Queue uses git cherry-pick to cherry-pick individual commits, it does not merge the branches in question. Cherry-picking is pretty much always the wrong thing to do; and in fact large parts of the Git community (including Linus Torvalds) are strictly against it. (When Linus was still running the Git project, he vehemently opposed adding cherry-pick support to Git and to this day he still refuses to merge any branches that contain cherry-picked commits.)

You should always prefer merging over cherry-picking.