Using both hg and git, in the same tree, carries no inherent conflict; as those programs were developed independently, it stands to reason that they don't interfere with one another.
However, and in this case, hg superimposes itself upon git (another way to see it is that the git repository depends on the underlying hg directory structure). As such, consider the following example, where you already have org-mode cloned and there is a patch waiting to be pulled from the online repository.
This is what hg may look like before you pull the changes from git:
c:\myfiles> hg log -l 1
changeset: 123:da5f372c3901
tag: tip
user: John Doe <john@doe.com>
date: Fri Jun 13 12:00:00 2014 -0500
summary: Some change in the work files
You then pull the changes to the org-mode from git. What matters here most, though, is that the pull action doesn't immediately reflect to the hg repository.
You can test whether the newer org-mode patches work. If they don't work right off the box, you should run hg revert --all, which will restore the way the repository looked like at the time of the latest commit. If they do work or you don't find any problems, you should commit a change under hg reflecting that you pulled a set of changes to the org-mode.
c:\myfiles> hg com -m "Pulling changes in org-mode"
c:\myfiles> hg log -l 1
changeset: 124:da5f372c3901
tag: tip
user: John Doe <john@doe.com>
date: Fri Jun 13 12:01:00 2014 -0500
summary: Pulling changes in org-mode
If git stores its metadata regarding the repository under the org-mode folder (i.e. as hg does with the .hg folder in the repository's root), there shouldn't be a problem with rolling back the commit under hg (if by any chance you, after commiting, find that there is a problem with org-mode):
c:\myfiles> hg rollback
rolling back last transaction
c:\myfiles> hg log -l 1
changeset: 123:da5f372c3901
tag: tip
user: John Doe <john@doe.com>
date: Fri Jun 13 12:01:00 2014 -0500
summary: Some change in the work files
Also, as stated on my comments, you can do this regardless of whatever VCS software you run. If you have:
c:\my_repo
c:\my_repo\2nd_repo
There wouldn't be a problem, as in order to work with each repository, you would have to work whilst inside the directory where you are working.
1 - I adapted some code from here because, as stated, I don't have much experience in the subject