¿Cómo selecciono una sola revisión en Mercurial?

Tonfa tiene razón. Lo que estás describiendo no es 'fusionar' (o 'empujar' o 'tirar'); es 'elegir'. Un push o un pull mueve todos los conjuntos de cambios de un repositorio a otro que no están ya en ese repositorio. Un 'merge' toma dos 'heads' y los fusiona en un nuevo conjunto de cambios que es la combinación de ambos.

Si realmente necesita mover G pero no puede soportar tener D,E, F allí, debe 'exportar hg' G desde el repositorio A, y luego 'importar hg' en el repositorio A. El Transplant extension es una envoltura alrededor de la exportación/importación con algunas sutilezas para ayudar a evitar mover el mismo conjunto de cambios varias veces.

Sin embargo, el inconveniente de usar import/export, transplant y cherry-picking en general es que realmente no se puede mover sobre G sin sus ancestros, porque en Mercurial el nombre de un conjunto de cambios es su 'hashid' que incluye los hashid de sus padres. Padres diferentes (el nuevo padre de G sería C y no F) significa a hashid diferente, así que ya no es G's es el trabajo de G sino un nuevo conjunto de cambios por nombre.

Moverse sobre G como algo nuevo, llamémoslo G' (Gee prime), no es un gran problema para algunos usos, pero para otros es una gran pita. Cuando pronto repo B consigue un nuevo conjunto de cambios, H, y desea moverlo sobre su padre va a cambiar de G a G', que tienen diferentes hashes. Eso significa que H se moverá como H ' chang 100 conjuntos de cambios en la línea y tendrás diferentes hashids para todo todo porque no podías soportar tener D,E, F en repo A.

Las cosas se descontrolarán aún más si/cuando quieras mover cosas del Repositorio A al Repositorio B (la dirección opuesta a tu movimiento anterior). Si intentas hacer un simple 'hg push' de A a B obtendrás G' (y H' y por descendientes posteriores) que serán duplicados de los conjuntos de cambios que ya tienes en Repo B.

¿Cuáles son entonces sus opciones?

1. No me importa. Sus datos todavía están ahí que acaba de terminar con los mismos conjuntos de cambios con diferentes nombres y más trabajo en futuros intercambios entre los dos repositorios. No está mal, es sólo un poco torpe tal vez, y a algunas personas no les importa.
2. Mueva todos los conjuntos de cambios D,E y F al Repositorio A. Puede mover todos los conjuntos de cambios si son inofensivos y evitar toda la molestia. Si no son tan inofensivos,puedes moverlos y luego hacer un 'hg backout' para deshacer los efectos de D, E y F en un nuevo conjunto de cambios H.
3. Dar G mejor parentesco para empezar. Es malo para mí mencionar esto porque es demasiado tarde para seguir este camino (sin editar el historial). Lo que debería haber hecho antes de trabajar en el conjunto de cambios G era hg update C. Si G no depende o requiere conjuntos de cambios D, E y F, entonces no debería ser su hijo.

Si en cambio actualizas a C primero tendrás un gráfico como este:

A - B - C - D - E - F
          \
            G

Entonces, la respuesta completa a esta pregunta sería simplemente hg push -r G ../repoA y G se movería limpiamente, mantener su mismo hashid, y D, E y F no iría con él.

ACTUALIZACIÓN:

Como se señala en los comentarios. Con Mercuriales modernos el comando hg graft es la manera perfecta de hacer esto.