Come fare in modo che git contrassegni un file eliminato e un nuovo come spostamento di file?

Ho spostato un file manualmente e poi l'ho modificato. Secondo Git, è un nuovo file e un file rimosso. C'è un modo per forzare Git a trattarlo come uno spostamento di file?

Git rileverà automaticamente lo spostamento / rinomina se la modifica non è troppo grave. Solo git addil nuovo file e git rmil vecchio file. git statusmostrerà quindi se ha rilevato la ridenominazione.

inoltre, per spostarsi tra le directory, potrebbe essere necessario:

1. cd all'inizio di quella struttura di directory.
2. Correre git add -A .
3. Esegui git statusper verificare che il "nuovo file" sia ora un file "rinominato"

Se lo stato di git mostra ancora "nuovo file" e non "rinominato", devi seguire i consigli di Hank Gay e fare le mosse e le modifiche in due commit separati.

Fai la mossa e la modifica in commit separati.

È tutto una cosa percettiva. Git è generalmente piuttosto bravo a riconoscere le mosse, perché GIT è un tracker di contenuti

Tutto ciò che dipende davvero è come la tua "stat" lo visualizza. L'unica differenza qui è il flag -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(-)

git help log

   -M
       Detect renames.

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

git diff -Mo git log -Mdovrebbe rilevare automaticamente tali cambiamenti come una ridenominazione con modifiche minori purché effettivamente lo siano. Se le modifiche minori non sono minori, è possibile ridurre la soglia di somiglianza, ad es

$ git log -M20 -p --stat

per ridurlo dal 50% al 20% predefinito.

Ecco una soluzione rapida e sporca per uno o pochi file rinominati e modificati che non sono stati salvati.

Diciamo che il file è stato chiamato fooe ora si chiama bar:

1. Rinomina barcon un nome temporaneo:

   mv bar side
   

2. Cassa foo:

   git checkout HEAD foo
   

3. Rinomina fooin barcon Git:

   git mv foo bar
   

4. Ora rinominare il file temporaneo in bar.

   mv side bar
   

Quest'ultimo passaggio è ciò che riporta il contenuto modificato nel file.

Mentre questo può funzionare, se il file spostato ha un contenuto troppo diverso da quello originale, considererà più efficiente decidere che si tratta di un nuovo oggetto. Lasciami dimostrare:

$ 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.

Se stai parlando di git statusnon mostrare i nomi, prova git commit --dry-run -ainvece

Se stai usando TortoiseGit è importante notare che il rilevamento automatico della ridenominazione di Git avviene durante il commit, ma il fatto che ciò accada non viene sempre visualizzato dal software in anticipo. Avevo spostato due file in una directory diversa ed eseguito alcune lievi modifiche. Uso TortoiseGit come strumento di commit e l'elenco Modifiche apportate mostrava che i file venivano eliminati e aggiunti, non spostati. L'esecuzione dello stato git dalla riga di comando ha mostrato una situazione simile. Tuttavia, dopo aver eseguito il commit dei file, sono stati rinominati nel registro. Quindi la risposta alla tua domanda è, fintanto che non hai fatto nulla di troppo drastico, Git dovrebbe riprendere automaticamente la ridenominazione.

Modifica: apparentemente se aggiungi i nuovi file e poi esegui uno stato git dalla riga di comando, la ridenominazione dovrebbe apparire prima di confermare.

Modifica 2: Inoltre, in TortoiseGit, aggiungi i nuovi file nella finestra di dialogo di commit, ma non impegnarli. Quindi se vai nel comando Show Log e guardi la directory di lavoro, vedrai se Git ha rilevato la ridenominazione prima di confermare.

La stessa domanda è stata sollevata qui: https://tortoisegit.org/issue/1389 ed è stata registrata come un bug da correggere qui: https://tortoisegit.org/issue/1440 Si scopre che è un problema di visualizzazione con il commit di TortoiseGit finestra di dialogo e esiste anche in stato git se non hai aggiunto i nuovi file.

Oppure puoi provare la risposta a questa domanda qui da Amber ! Per citare di nuovo:

Innanzitutto, annulla l'aggiunta graduale per il file spostato manualmente:

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

Quindi, usa Git per spostare il file:

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

Ovviamente, se hai già eseguito il trasferimento manuale, potresti voler ripristinare la revisione prima dello spostamento e poi semplicemente uscire da lì.

Utilizzare il git mvcomando per spostare i file, anziché i comandi di spostamento del sistema operativo: https://git-scm.com/docs/git-mv

Nota che il git mvcomando esiste solo nelle versioni Git 1.8.5 e successive. Quindi potresti dover aggiornare Git per usare questo comando.

Ho avuto questo problema di recente, quando ho spostato (ma non modificato) alcuni file.

Il problema è che Git ha cambiato alcune terminazioni di riga quando ho spostato i file e quindi non sono stato in grado di dire che i file erano gli stessi.

utilizzando git mv risolto il problema, ma funziona solo su singoli file / directory, e ho avuto un sacco di file nella radice del repository da fare.

Un modo per risolvere questo problema sarebbe con un po 'di magia bash / batch.

Un altro modo è il seguente

• Sposta i file e git commit . Questo aggiorna le terminazioni di riga.
• Spostare i file nella loro posizione originale, ora che hanno i nuovi finali di riga e git commit --amend
• Spostare di nuovo i file e git commit --amend. Questa volta non ci sono cambiamenti ai finali di linea, quindi Git è felice

Per me ha funzionato per salvare tutte le modifiche prima del commit e saltarle di nuovo. Ciò ha reso git riesaminare i file aggiunti / eliminati e li ha contrassegnati correttamente come spostati.

Esiste probabilmente un modo migliore di "riga di comando" per farlo, e so che si tratta di un hack, ma non sono mai stato in grado di trovare una buona soluzione.

Utilizzo di TortoiseGIT: se si dispone di un commit GIT in cui alcune operazioni di spostamento dei file vengono visualizzate come carico di aggiunte / eliminazioni anziché rinominazioni, anche se i file presentano solo piccole modifiche, procedere come segue:

1. Controlla cosa hai fatto localmente
2. Effettua il check in una mini modifica di una riga in un secondo commit
3. Vai al registro GIT in guscio di tartaruga
4. Seleziona i due commit, fai clic con il pulsante destro del mouse e seleziona "Unisci in un commit"

Il nuovo commit ora mostrerà correttamente i nomi dei file ... che aiuteranno a mantenere la cronologia dei file corretta.

Quando modifico, rinomino e sposto un file contemporaneamente, nessuna di queste soluzioni funziona. La soluzione è farlo in due commit (modifica e rinomina / sposta separati) e quindi fixupil secondo commit tramite git rebase -iper averlo in un commit.

Il modo in cui capisco questa domanda è "Come far riconoscere a git la cancellazione di un vecchio file e la creazione di un nuovo file come mossa di un file".

Sì nella directory di lavoro dopo aver eliminato un vecchio file e inserito un vecchio file, git statusverrà visualizzato " deleted: old_file" e " Untracked files: ... new_file"

Ma nell'indice / livello di gestione temporanea una volta aggiunto e rimosso il file usando git, verrà riconosciuto come spostamento di file. Per fare ciò, supponendo che tu abbia fatto la cancellazione e la creazione usando il tuo Sistema Operativo, dai i seguenti comandi:

git add new_file
git rm old_file

Se il contenuto del file è simile al 50% o più, il git statuscomando in esecuzione dovrebbe fornire:

renamed: old_file -> new_file