remove - git tags best practices
Backport cambia de archivo renombrado (7)
Ante el mismo problema, le pregunté a un colega qué haría él, y su respuesta instantánea fue:
git checkout production
git mv production-filename trunk-filename && git commit -m "Just fooling git"
git cherry-pick trunk-commit
git mv trunk-filename production-filename && git commit -m "Undo the damage"
# Now squash the 3 commits
git rebase -i HEAD~3
Trabajó como un encanto para mí.
Tengo dos ramas: tronco, producción. He encontrado un problema en el tronco, lo he arreglado y lo he cometido, lo he empujado. Ahora se probó y necesito fusionar los cambios en la rama de producción como un hotfix. Intento usar el pico de cereza. Sin embargo, no funciona porque un archivo (s) cambiado en la solución se cambió de nombre en el troncal anteriormente durante una refactorización que no quiero que se ponga en producción.
No quiero fusionar todo, pero tome solo este compromiso. La selección de cerebros falla con el conflicto "eliminado por nosotros" (por supuesto, el nuevo archivo nunca existió en la rama de producción).
¿Cuál es la forma correcta de traer los cambios al archivo anterior?
Esto es un poco complicado. Por ejemplo, puede crear un parche desde un diff y aplicarlo al archivo anterior. Pero en el futuro, para evitar estos problemas, recomiendo hacer arreglos en la rama de producción y probarlos allí primero, luego fusionarlos desde la producción hasta el tronco.
Hice un script de shell que intenta realizar una selección desde el punto de vista mientras adivina que el archivo se mueve (no funciona si cambió el nombre del archivo, solo si lo movió a otra carpeta): Sin embargo, actualmente fallará si se agrega la confirmación Archivos nuevos o si se cambia el nombre de los archivos.
#!/bin/bash
#
# Attemps to guess file moves (rename of folders) when cherry-pick''ing.
# Gaspard van Koningsveld
#
[ "$1" == "" ] && echo "usage: $0 <commit-hash-to-cherry-pick>" && exit 1
TMP_PATCH_FILE="temp-cherry-pick-patch"
function abort() {
echo "Aborting"
"rm" -f "$TMP_PATCH_FILE"
exit 1
}
function main() {
echo "Retreiving commit patch..."
"git" show "$1" > "$TMP_PATCH_FILE" || abort
echo "Matching renamed files..."
sedcmds=""
for oldfile in $("grep" -E ''(--- a|/+/+/+ b)'' "$TMP_PATCH_FILE" | "cut" -c 7- | "sort" | "uniq"); do
[ -f "$oldfile" ] && continue
renamefound=0
oldfilepart="$oldfile"
while [ $renamefound -eq 0 ]; do
possiblefiles=$("git" ls-files "**/$oldfilepart")
if [ "$possiblefiles" != "" ]; then
if [ $("wc" -l <<< "$possiblefiles") == "1" ]; then
echo " $oldfile > $possiblefiles"
sedcmds="$sedcmds s|/$oldfile|/$possiblefiles|g;"
break
else
echo " ERROR: More than one rename possibility found for file $oldfile:"
echo "$possiblefiles"
abort
fi
fi
prevoldfilepart="$oldfilepart"
oldfilepart="${oldfilepart#*/}"
if [ "$prevoldfilepart" == "$oldfilepart" ]; then
echo " ERROR: Could not find rename for $oldfile."
abort
fi
done
done
echo "Renaming files in patch..."
"sed" -i "$sedcmds" "$TMP_PATCH_FILE" || abort
echo "Applying patch as new commit..."
"sed" -i "s/^commit /From commit /;s/^Author: /From: /" "$TMP_PATCH_FILE" || abort
"git" am -3 "$TMP_PATCH_FILE"
"rm" -f "$TMP_PATCH_FILE"
}
main "$@"
Para seleccionar cambios en cualquier número de archivos, en caso de que se cambie el nombre de un directorio a otro de las sucursales:
git diff ... | sed -e ''s|<old dir>|<new dir>|'' | git apply -
Si:
- Usted esperaba / esperaba que Git detectara el movimiento o cambio de nombre del archivo en el tronco, pero no lo hizo, y
- Su repositorio tiene un número razonable de archivos.
... entonces definitivamente deberías considerar cambiar tu configuración de git de esta manera:
$ git config merge.renameLimit 999999
Es posible que durante un merge / cherry-pick, git esté alcanzando el límite de comprobación del archivo predeterminado (creo que es 400 o 1000 o algo así) antes de poder localizar la coincidencia de cambio de nombre adecuada. El aumento de este límite puede hacer que la fusión / selección de cerebros tarde más tiempo mientras busca su archivo cuyo nombre ha cambiado, pero puede ayudar a evitar los desafíos de combinación "eliminados por nosotros".
Eso debería hacer el truco, pero si su archivo renombrado era pequeño y los cambios entre las ramas son significativos, también podría jugar con la configuración de -X rename-threshold , por ejemplo, reducirlo del 50% predeterminado con -X rename-threshold=25% .
Tengo el mismo problema y he tratado de encontrar una solución.
Resolví utilizando una secuencia de rebases. No he realizado más pruebas que estas, ¡así que úselo bajo su propio riesgo!
Si estás interesado échale un vistazo en github:
Yo usaría un buen parche viejo para esto:
git show COMMIT_ID -- old/file/name.txt | patch new/file/name.txt