Me preocupa olvidarme de esta ingeniosa característica la próxima vez que la necesite.
Git 2.13 (Q2 2017) explica por qué no existe una "protección" contra el olvido de esta opción de inserción, porque incluso si no la olvida en el git pushnivel, aún podría ignorarse.
Ver commit f17d642 (19 abr 2017) por Ævar Arnfjörð Bjarmason ( avar) .
(Fusionada por Junio C Hamano - gitster- en commit 46bdfa3 , 26 abr 2017)
push: documento y prueba --force-with-leasecon múltiples controles remotos
Documente y pruebe los casos en los que hay dos controles remotos que apuntan a la misma URL, y una búsqueda en segundo plano y posterior git push --force-with-leaseno deberían detectar referencias no actualizadas que no hemos obtenido.
Algunos editores, como el VSC de Microsoft, tienen una función para buscar automáticamente en segundo plano, lo que evita las protecciones ofrecidas por --force-with-lease&--force-with-lease=<refname> , como se indica en la documentación que se agrega aquí.
Entonces la documentación porgit push ahora incluye:
nota general sobre seguridad: proporcionar esta opción sin un valor esperado, es decir, como --force-with-leaseo --force-with-lease=<refname>
interactúa muy mal con cualquier cosa que implícitamente se ejecute git fetchen el control remoto para ser empujado en segundo plano, por ejemplogit fetch origin
en su repositorio en un cronjob.
La protección que ofrece sobre --force es garantizar que los cambios posteriores en los que su trabajo no se basó no se vean afectados, pero esto se vence trivialmente si algún proceso en segundo plano actualiza las referencias en segundo plano. No tenemos nada más que la información de seguimiento remoto para seguir como una heurística para los árbitros que se espera que hayas visto y estés dispuesto a chasquear.
Si su editor o algún otro sistema se está ejecutando git fetchen segundo plano, una forma de mitigar esto es simplemente configurar otro control remoto:
git remote add origin-push $(git config remote.origin.url)
git fetch origin-push
Ahora, cuando se ejecuta git fetch originel proceso en segundo plano, las referencias origin-pushno se actualizarán y, por lo tanto, comandos como:
git push --force-with-lease origin-push
Fallará a menos que lo ejecute manualmente git fetch origin-push.
Por supuesto, este método es completamente derrotado por algo que se ejecuta git fetch
--all, en ese caso, deberá deshabilitarlo o hacer algo más tedioso como:
git fetch # update 'master' from remote
git tag base master # mark our base point
git rebase -i master # rewrite some commits
git push --force-with-lease=master:base master:master
Es decir, cree una baseetiqueta para las versiones del código ascendente que haya visto y esté dispuesto a sobrescribir, luego reescriba el historial y, finalmente, fuerce los cambios automáticos mastersi la versión remota todavía está en base, independientemente de a qué remotes/origin/masterse haya actualizado su local en el antecedentes.
rmarm -ien su .bashrc; algún día olvidará y eliminará un archivo importante en un servidor. Ir con tu propio alias no tiene ese problema :)