Linus Torvalds <torva...@linux-foundation.org> writes: > On Fri, Mar 18, 2016 at 1:21 PM, Junio C Hamano <gits...@pobox.com> wrote: >> While it makes sense to allow merging unrelated histories of two >> projects that started independently into one, in the way "gitk" was >> merged to "git" itself aka "the coolest merge ever", such a merge is >> still an unusual event. Worse, if somebody creates an independent >> history by starting from a tarball of an established project and >> sends a pull request to the original project, "git merge" however >> happily creates such a merge without any sign of something unusual >> is happening. >> >> Teach "git merge" to refuse to create such a merge by default, >> unless the user passes a new "--allow-unrelated-histories" option to >> tell it that the user is aware that two unrelated projects are >> merged. > > Heh. I had a separate set of patches for you, but hadn't sent them out > because of the other test failures (which you also worked out).
I was reviewing the topics to merge to 'master', and a thought crossed my mind. Both of our series only refuse to create a merge that does not have any common ancestor, but shouldn't the right solution refuse to add a new root? That is, somebody may - Create a new root by mistake; - Pull from you to update, with --allow-unrelated-histories option; - Optionally, build more history on top of it; and then finally - Ask you to pull without telling you that there is a new root. Wouldn't the "git pull" you do in response to this pull request have a common ancestor (i.e. the tip of what he pulled from you in the second step) and evade this check? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
