¿Cómo hacer que git marque un archivo eliminado y uno nuevo como un movimiento de archivo?

Moví un archivo manualmente y luego lo modifiqué. Según Git, es un archivo nuevo y un archivo eliminado. ¿Hay alguna forma de obligar a Git a tratarlo como un movimiento de archivo?

Git detectará automáticamente el movimiento / cambio de nombre si su modificación no es demasiado severa. Solo git addel archivo nuevo y git rmel archivo viejo. git statusluego mostrará si ha detectado el cambio de nombre.

Además, para moverse por los directorios, es posible que deba:

1. cd a la parte superior de esa estructura de directorios.
2. correr git add -A .
3. Ejecute git statuspara verificar que el "nuevo archivo" ahora es un archivo "renombrado"

Si el estado de git aún muestra "nuevo archivo" y no "renombrado", debe seguir el consejo de Hank Gay y hacer el movimiento y la modificación en dos confirmaciones separadas.

Realice el movimiento y la modificación en confirmaciones separadas.

Todo es una cosa perceptiva. Git es generalmente bastante bueno para reconocer movimientos, porque GIT es un rastreador de contenido

Todo lo que realmente depende es cómo lo muestre su "estadística". La única diferencia aquí es la bandera -M.

git log --stat -M

commit 9c034a76d394352134ee2f4ede8a209ebec96288
Author: Kent Fredric
Date:   Fri Jan 9 22:13:51 2009 +1300


        Category Restructure

     lib/Gentoo/Repository.pm                |   10 +++++-----
     lib/Gentoo/{ => Repository}/Base.pm     |    2 +-
     lib/Gentoo/{ => Repository}/Category.pm |   12 ++++++------
     lib/Gentoo/{ => Repository}/Package.pm  |   10 +++++-----
     lib/Gentoo/{ => Repository}/Types.pm    |   10 +++++-----
     5 files changed, 22 insertions(+), 22 deletions(-)

git log --stat

commit 9c034a76d394352134ee2f4ede8a209ebec96288
Author: Kent Fredric
Date:   Fri Jan 9 22:13:51 2009 +1300

    Category Restructure

 lib/Gentoo/Base.pm                |   36 ------------------------
 lib/Gentoo/Category.pm            |   51 ----------------------------------
 lib/Gentoo/Package.pm             |   41 ---------------------------
 lib/Gentoo/Repository.pm          |   10 +++---
 lib/Gentoo/Repository/Base.pm     |   36 ++++++++++++++++++++++++
 lib/Gentoo/Repository/Category.pm |   51 ++++++++++++++++++++++++++++++++++
 lib/Gentoo/Repository/Package.pm  |   41 +++++++++++++++++++++++++++
 lib/Gentoo/Repository/Types.pm    |   55 +++++++++++++++++++++++++++++++++++++
 lib/Gentoo/Types.pm               |   55 -------------------------------------
 9 files changed, 188 insertions(+), 188 deletions(-)

registro de ayuda de git

   -M
       Detect renames.

   -C
       Detect copies as well as renames. See also --find-copies-harder.

git diff -Mo git log -Mdebería detectar automáticamente tales cambios como un cambio de nombre con cambios menores , siempre que realmente lo sean. Si sus cambios menores no son menores, puede reducir la similitud que existe, p. Ej.

$ git log -M20 -p --stat

para reducirlo del 50% predeterminado al 20%.

Aquí hay una solución rápida y sucia para uno o unos pocos archivos renombrados y modificados que no están comprometidos.

Digamos que el archivo se llamó fooy ahora se llama bar:

1. Cambiar el nombre bara un nombre temporal:

   mv bar side
   

2. Pago foo:

   git checkout HEAD foo
   

3. Renombrar fooa barcon Git:

   git mv foo bar
   

4. Ahora cambie el nombre de su archivo temporal a bar.

   mv side bar
   

Este último paso es lo que recupera el contenido modificado en el archivo.

Si bien esto puede funcionar, si el archivo movido es demasiado diferente en contenido del git original, se considerará más eficiente decidir que este es un objeto nuevo. Déjame demostrarte:

$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    renamed:    README -> README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   README.md
    modified:   work.js

$ git add README.md work.js # why are the changes unstaged, let's add them.
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    deleted:    README
    new file:   README.md
    modified:   work.js

$ git stash # what? let's go back a bit
Saved working directory and index state WIP on dir: f7a8685 update
HEAD is now at f7a8685 update
$ git status
On branch workit
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .idea/

nothing added to commit but untracked files present (use "git add" to track)
$ git stash pop
Removing README
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    new file:   README.md

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    README
    modified:   work.js

Dropped refs/stash@{0} (1ebca3b02e454a400b9fb834ed473c912a00cd2f)
$ git add work.js
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    new file:   README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    README

$ git add README # hang on, I want it removed
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    deleted:    README
    new file:   README.md
    modified:   work.js

$ mv README.md Rmd # Still? Try the answer I found.
$ git checkout README
error: pathspec 'README' did not match any file(s) known to git.
$ git checkout HEAD README # Ok the answer needed fixing.
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    new file:   README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    README.md
    modified:   work.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    Rmd

$ git mv README README.md
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    renamed:    README -> README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   work.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    Rmd

$ mv Rmd README.md
$ git status
On branch workit
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   .gitignore
    renamed:    README -> README.md
    modified:   work.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   README.md
    modified:   work.js

$ # actually that's half of what I wanted; \
  # and the js being modified twice? Git prefers it in this case.

Si está hablando de git statusno mostrar los cambios de nombre, intente en su git commit --dry-run -alugar

Si está utilizando TortoiseGit, es importante tener en cuenta que la detección automática de cambio de nombre de Git ocurre durante la confirmación, pero el hecho de que esto suceda no siempre se muestra por adelantado por el software. Moví dos archivos a un directorio diferente y realicé algunas pequeñas modificaciones. Uso TortoiseGit como mi herramienta de confirmación y la lista Cambios realizados mostró que los archivos se eliminaron y agregaron, no se movieron. Ejecutar el estado de git desde la línea de comando mostró una situación similar. Sin embargo, después de confirmar los archivos, aparecieron como renombrados en el registro. Entonces, la respuesta a su pregunta es, siempre que no haya hecho nada demasiado drástico, Git debería elegir el cambio de nombre automáticamente.

Editar: Aparentemente, si agrega los nuevos archivos y luego realiza un estado git desde la línea de comando, el cambio de nombre debería aparecer antes de comprometerse.

Edición 2: Además, en TortoiseGit, agregue los nuevos archivos en el diálogo de confirmación, pero no los confirme. Luego, si ingresa al comando Mostrar registro y mira el directorio de trabajo, verá si Git ha detectado el cambio de nombre antes de comprometerse.

Aquí se planteó la misma pregunta: https://tortoisegit.org/issue/1389 y se ha registrado como un error para solucionarlo aquí: https://tortoisegit.org/issue/1440 Resulta que es un problema de visualización con el compromiso de TortoiseGit diálogo y también existe en estado git si no ha agregado los nuevos archivos.

¡O podría intentar la respuesta a esta pregunta aquí por Amber ! Para citarlo de nuevo:

Primero, cancele su complemento por etapas para el archivo movido manualmente:

$ git reset path/to/newfile
$ mv path/to/newfile path/to/oldfile

Luego, use Git para mover el archivo:

$ git mv path/to/oldfile path/to/newfile

Por supuesto, si ya cometió el movimiento manual, es posible que desee restablecer la revisión antes del movimiento, y luego simplemente git mv desde allí.

Use el git mvcomando para mover los archivos, en lugar de los comandos de movimiento del sistema operativo: https://git-scm.com/docs/git-mv

Tenga en cuenta que el git mvcomando solo existe en las versiones de Git 1.8.5 y posteriores. Por lo tanto, es posible que deba actualizar su Git para usar este comando.

Recientemente tuve este problema al mover (pero no modificar) algunos archivos.

El problema es que Git cambió algunas terminaciones de línea cuando moví los archivos, y luego no pude decir que los archivos eran iguales.

El uso git mvsolucionó el problema, pero solo funciona en archivos / directorios individuales, y tenía muchos archivos en la raíz del repositorio para hacer.

Una forma de arreglar esto sería con algo de magia bash / batch.

Otra forma es la siguiente

• Mueve los archivos y git commit. Esto actualiza los finales de línea.
• Vuelva a mover los archivos a su ubicación original, ahora que tienen las nuevas terminaciones de línea, y git commit --amend
• Mueva los archivos nuevamente y git commit --amend. Esta vez no hay cambios en los finales de línea, así que Git está feliz.

Para mí funcionó guardar todos los cambios antes de la confirmación y sacarlos nuevamente. Esto hizo que git volviera a analizar los archivos agregados / eliminados y los marcó correctamente como movidos.

Probablemente hay una mejor forma de "línea de comando" para hacer esto, y sé que esto es un truco, pero nunca he podido encontrar una buena solución.

Uso de TortoiseGIT: si tiene una confirmación GIT donde algunas operaciones de movimiento de archivos se muestran como carga de adiciones / eliminaciones en lugar de cambios de nombre, a pesar de que los archivos solo tienen pequeños cambios, haga esto:

1. Comprueba lo que has hecho localmente
2. Registre un mini cambio de una línea en una segunda confirmación
3. Ir a GIT iniciar sesión tortuga git
4. Seleccione las dos confirmaciones, haga clic derecho y seleccione "fusionar en una confirmación"

La nueva confirmación ahora mostrará correctamente el cambio de nombre de los archivos ... lo que ayudará a mantener el historial de archivos adecuado.

Cuando edito, renombre y muevo un archivo al mismo tiempo, ninguna de estas soluciones funciona. La solución es hacerlo en dos confirmaciones (editar y renombrar / mover separadamente) y luego fixupla segunda confirmación git rebase -ipara tenerlo en una confirmación.

La forma en que entiendo esta pregunta es "Cómo hacer que git reconozca la eliminación de un archivo antiguo y la creación de un nuevo archivo como movimiento de archivo".

Sí, en el directorio de trabajo, una vez que elimine un archivo antiguo e inserte un archivo antiguo, git statusdirá " deleted: old_file" y " Untracked files: ... new_file"

Pero en el índice / nivel provisional una vez que agregue y elimine el archivo usando git, se reconocerá como un movimiento de archivo. Para hacerlo, suponiendo que haya realizado la eliminación y creación utilizando su Sistema Operativo, dé los siguientes comandos:

git add new_file
git rm old_file

Si el contenido del archivo es similar al 50% o más, ejecutar el git statuscomando debería proporcionarle:

renamed: old_file -> new_file