Josué, miembro de este gran staff, nos ha hecho el favor de redactar esta reseña porque domina muy bien dicho tema.
Solución:
Una refspec le dice a git cómo mapear referencias desde un repositorio remoto al repositorio local.
El valor que enumeró fue +refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*; así que analicemos eso.
Tienes dos patrones con un espacio entre ellos; esto solo significa que estás dando múltiples reglas. (El libro pro git se refiere a esto como dos especificaciones de referencia; lo que probablemente sea técnicamente más correcto. Sin embargo, casi siempre tiene la capacidad de enumerar varias especificaciones de referencia si es necesario, por lo que en la vida cotidiana es probable que haga poca diferencia).
El primer patrón, entonces, es +refs/heads/*:refs/remotes/origin/* que tiene tres partes:
- Él
+significa aplicar la regla sin fallar, incluso si hacerlo movería una referencia de destino de una manera que no sea de avance rápido. Volveré a eso. - La parte anterior a la
:(pero después de la+si hay uno) es el patrón de “fuente”. Eso esrefs/heads/*lo que significa que esta regla se aplica a cualquier referencia remota bajorefs/heads(significado, ramas). - La parte después de la
:es el patrón de “destino”. Eso esrefs/remotes/origin/*.
Así que si el origen tiene una rama masterrepresentado como refs/heads/masteresto creará una referencia de sucursal remota origin/master representado como refs/remotes/origin/master. Y así sucesivamente para cualquier nombre de rama (*).
Así que volvamos a eso +… supongamos que el origen tiene
A --- B <--(master)
Obtienes y, aplicando esa especificación de referencia, obtienes
A --- B <--(origin/master)
(Si aplicó reglas de seguimiento típicas e hizo un pull tu también tienes master señaló a B.)
A --- B <--(origin/master)(master)
Ahora algunas cosas suceden en el control remoto. Alguien tal vez hizo un reset que borró Bluego comprometido C, luego forzó un empujón. Así dice el control remoto
A --- C <--(master)
Cuando buscas, obtienes
A --- B
C
y git debe decidir si permite el movimiento de origin/master desde B para C. De forma predeterminada, no permitiría esto porque no es un avance rápido (le diría que rechazó el tirón para esa referencia), sino porque la regla comienza con + lo aceptará.
A --- B <--(master)
C <--(origin/master)
(En este caso, una extracción dará como resultado una confirmación de fusión).
El segundo patrón es similar, pero para merge-requests refs (que supongo que está relacionado con la implementación de PR de su servidor; no estoy familiarizado con eso).
Más sobre refspecs: https://git-scm.com/book/en/v2/Git-Internals-The-Refspec
Recuerda dar difusión a este ensayo si te ayudó.