tag - El mapeo uno a uno de git se compromete con los conjuntos de cambios TFS usando git-tfs rcheckin

git push tag

Question

El contexto

• Tenemos un repositorio de git con una rama de lanzamiento.
• Tenemos un repositorio de TFS (actualmente vacío).

Mi tarea es reflejar la rama de publicación del repositorio de git en TFS para que cada confirmación en git corresponda a un conjunto de cambios en TFS. Todos los desarrolladores solo se comprometen con git y (supongamos) desconocen TFS.

Leer la documentación de rcheckin y la respuesta a este problema relacionado me hace creer que rcheckin es capaz de hacerlo.

El problema

Todos los commits en git son aplastados en un solo conjunto de cambios.

Secuencia de reproducción:

git tfs clone http://tfs:8080 $/tfsrepo
cd tfsrepo
git remote add github [email protected]:REPO/Repo.git
git fetch github
git merge github/release
git tfs rcheckin

Esto da como resultado una sola entrada en TFS que contiene todas las confirmaciones.

Otros intentos de resolver el problema

• Después del clon, combine el primer commit desde el repositorio de origen (git), rcheckin para crear una base compartida

  • Esto funcionó, pero la posterior git pull github release seguida de git-tfs rcheckin condujo a confirmar el aplastamiento nuevamente.

• Para los primeros commits en el repositorio de origen, los fusioné uno por uno en el repositorio compartido de git-tfs y comprobé después de cada uno.

  • Este tipo de trabajo, como para cada compromiso, hubo un conjunto de cambios en TFS. Sin embargo, el mensaje de confirmación original se encuentra debajo del mensaje "c02436de4f .. combinado".
  • No es realista hacer para cada conjunto de cambios, incluso con secuencias de comandos.
  • Como señalaron los patthoyts , esto me haría el responsable de ese cambio en lo que respecta a TFS.

Mi pregunta

¿Qué debo hacer para mantener a TFS actualizado con la rama de publicación de git-repo para que cada confirmación en git tenga un conjunto de cambios TFS correspondiente?

información adicional

Tengo el control administrativo de ambos repos, y podría volver a calcular el git repo si fuera necesario, con todas las consecuencias que esto implica. Simplemente no quiero perder la historia que ya hemos creado.

Answer 1

Creo que lo que estás viendo es que git-tfs usa solo commits a lo largo de la ruta más corta entre HEAD y tfs / default. La historia de TFS es una lista de cambios, mientras que git es un gráfico, y estás logrando el desajuste de impedancia entre los dos. Para obtener una git log --graph --oneline --decorate HEAD tfs/default de lo que está viendo git-tfs, pruebe git log --graph --oneline --decorate HEAD tfs/default antes de usar rcheckin.

Si quieres el 1: 1 :: commit: changeset, prueba esto:

git tfs clone http://tfs:8080 $/tfsrepo
cd tfsrepo
git remote add github [email protected]:REPO/Repo.git
git fetch github
git tfs rcheckin github/release

Otro enfoque es usar cherry-pick o rebase .

git tfs clone http://tfs:8080 $/tfsrepo
cd tfsrepo
git remote add github [email protected]:REPO/Repo.git
git fetch github
git checkout -b about-to-be-rewritten-twice github/release
git rebase tfs/default
git tfs rcheckin

Consulte los documentos de rebase para obtener más ejemplos de cosas que la rebase puede hacer.

Y no git push github about-to-be-rewritten-twice:release .

Answer 2

No creo que esto salga bien. Si arregla la realización de las confirmaciones, cada una tendrá la marca de tiempo y la identificación del usuario desde el momento en que accedió a TFS. No puede conservar el autor original o la hora al enviarlos a TFS. Es mejor que espere mientras Microsoft anuncia que TFS respaldará en el futuro a Git. Así que, en poco tiempo, cualquiera que necesite usar tfs puede actualizar sus herramientas y acceder a su repositorio de git real.

Sospecho que tu combinación hizo un commit de fusión y eso está causando el squash. Puede intentar restablecer la rama git-tfs a su maestro de git y luego presionar las confirmaciones. Usamos git-tfs al revés donde el repositorio compartido es TFS y todos usamos git con git tfs para hacer commits. Si creo una rama y agrego algunas confirmaciones, entonces git tfs rcheckin no las git tfs rcheckin en una, sino que git tfs rcheckin una serie que coincide con la que tengo en mi git local. Encontré que usar ''escenario'' y luego desestabilizar en tfs para hacer que un commit aplastara todo en uno. No dijiste por qué tienes que copiar a TFS, pero te sugiero que intentes señalar los recientes anuncios de Microsoft y decirles que es el futuro. Incluso con TFS. :)