Como fazer com que o git marque um arquivo excluído e um novo como um arquivo é movido?

Mudei um arquivo manualmente e depois o modifiquei. De acordo com o Git, é um novo arquivo e um arquivo removido. Existe alguma maneira de forçar o Git a tratá-lo como uma movimentação de arquivo?

O Git detectará automaticamente a mudança / renomeação se sua modificação não for muito severa. Apenas git addo novo arquivo e git rmo arquivo antigo. git statusmostrará se detectou a renomeação.

Além disso, para movimentar diretórios, pode ser necessário:

1. cd na parte superior dessa estrutura de diretório.
2. Corre git add -A .
3. Execute git statuspara verificar se o "novo arquivo" agora é um arquivo "renomeado"

Se o status do git ainda mostra "novo arquivo" e não "renomeado", você precisa seguir o conselho de Hank Gay, fazer a movimentação e modificar em dois commits separados.

Faça a movimentação e a modificação em confirmações separadas.

É tudo uma coisa perceptiva. O Git geralmente é bom em reconhecer movimentos, porque o GIT é um rastreador de conteúdo

Tudo o que realmente depende é como o seu "stat" exibe. A única diferença aqui é o sinalizador -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(-)

log de ajuda do git

   -M
       Detect renames.

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

git diff -Mou git log -Mdeve detectar automaticamente tais alterações, como uma renomeação, com pequenas alterações , desde que realmente sejam. Se suas pequenas alterações não forem menores, você poderá reduzir a semelhança;

$ git log -M20 -p --stat

reduzi-lo dos 50% para 20% padrão.

Aqui está uma solução rápida e suja para um ou alguns arquivos renomeados e modificados que não foram confirmados.

Digamos que o arquivo foi nomeado fooe agora é nomeado bar:

1. Renomeie barpara um nome temporário:

   mv bar side
   

2. Saída foo:

   git checkout HEAD foo
   

3. Renomeie foopara barcom Git:

   git mv foo bar
   

4. Agora renomeie seu arquivo temporário para bar.

   mv side bar
   

Esta última etapa é o que coloca seu conteúdo alterado de volta no arquivo.

Embora isso possa funcionar, se o arquivo movido tiver um conteúdo muito diferente do git original, será mais eficiente decidir que esse é um novo objeto. Deixe-me demonstrar:

$ 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 você está falando git statusnão mostrando as renomeações, tente git commit --dry-run -aem vez

Se você estiver usando o TortoiseGit, é importante observar que a detecção automática de renomeação do Git ocorre durante o commit, mas o fato de que isso vai acontecer nem sempre é exibido pelo software de antemão. Mudei dois arquivos para um diretório diferente e realizei algumas edições leves. Eu uso o TortoiseGit como minha ferramenta de confirmação e a lista Alterações feitas mostra os arquivos sendo excluídos e adicionados, não movidos. A execução do status git na linha de comando mostrou uma situação semelhante. No entanto, após confirmar os arquivos, eles apareceram como sendo renomeados no log. Portanto, a resposta para sua pergunta é: desde que você não tenha feito algo muito drástico, o Git deve mudar o nome automaticamente.

Editar: Aparentemente, se você adicionar os novos arquivos e, em seguida, executar um status git na linha de comando, a renomeação deverá aparecer antes de confirmar.

Editar 2: Além disso, no TortoiseGit, adicione os novos arquivos na caixa de diálogo de confirmação, mas não os confirme. Então, se você entrar no comando Show Log e examinar o diretório de trabalho, verá se o Git detectou a renomeação antes de confirmar.

A mesma pergunta foi levantada aqui: https://tortoisegit.org/issue/1389 e foi registrada como um bug para corrigir aqui: https://tortoisegit.org/issue/1440 Acontece que é um problema de exibição no commit do TortoiseGit diálogo e também existe no status git se você não adicionou os novos arquivos.

Ou você pode tentar a resposta a esta pergunta aqui de Amber ! Para citar novamente:

Primeiro, cancele sua adição faseada para o arquivo movido manualmente:

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

Em seguida, use Git para mover o arquivo:

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

Obviamente, se você já cometeu a movimentação manual, convém redefinir a revisão antes da mudança e simplesmente git mv a partir daí.

Use o git mvcomando para mover os arquivos, em vez dos comandos de movimentação do SO: https://git-scm.com/docs/git-mv

Observe que o git mvcomando existe apenas nas versões 1.8.5 e superior do Git. Então você pode ter que atualizar seu Git para usar este comando.

Eu tive esse problema recentemente, ao mover (mas não modificar) alguns arquivos.

O problema é que o Git alterou algumas terminações de linha quando mudei os arquivos e não soube dizer que os arquivos eram os mesmos.

Usando git mvresolvido o problema, mas ele só funciona em arquivos / diretórios únicos, e eu tinha muitos arquivos na raiz do repositório para fazer.

Uma maneira de consertar isso seria com alguma mágica de bash / batch.

Outra maneira é a seguinte

• Mova os arquivos e git commit. Isso atualiza as terminações de linha.
• Mova os arquivos de volta para o local original, agora que eles têm as novas terminações de linha e git commit --amend
• Mova os arquivos novamente e git commit --amend. Desta vez, não há alterações nas terminações da linha, portanto o Git está feliz

Para mim, trabalhou para esconder todas as alterações antes do commit e exibi-las novamente. Isso fez o git re-analisar os arquivos adicionados / excluídos e os marcou corretamente como movidos.

Provavelmente existe uma maneira melhor de "linha de comando" para fazer isso, e eu sei que isso é um hack, mas nunca consegui encontrar uma boa solução.

Usando o TortoiseGIT: Se você possui uma confirmação GIT em que algumas operações de movimentação de arquivos são exibidas como carga de adições / exclusões em vez de renomear, mesmo que os arquivos tenham apenas pequenas alterações, faça o seguinte:

1. Verifique o que você fez localmente
2. Faça check-in de uma mini alteração de uma linha em uma segunda confirmação
3. Vá para o log do GIT no tartaruga git
4. Selecione as duas confirmações, clique com o botão direito e selecione "mesclar em uma confirmação"

A nova confirmação agora mostrará corretamente o nome do arquivo ... o que ajudará a manter o histórico adequado do arquivo.

Quando edito, renomeio e movo um arquivo ao mesmo tempo, nenhuma dessas soluções funciona. A solução é fazer isso em duas confirmações (editar e renomear / mover separadamente) e, em seguida, fixupa segunda confirmação via git rebase -itê-lo em uma confirmação.

A maneira como entendo essa pergunta é "Como fazer o git reconhecer a exclusão de um arquivo antigo e a criação de um novo arquivo à medida que o arquivo é movido".

Sim no diretório de trabalho, uma vez que você exclua um arquivo antigo e inseriu um arquivo antigo, git statusdirá " deleted: old_file" e " Untracked files: ... new_file"

Porém, no índice / nível de armazenamento temporário, depois de adicionar e remover arquivos usando o git, ele será reconhecido como uma movimentação de arquivos. Para fazer isso, supondo que você tenha excluído e criado usando o Sistema Operacional, forneça os seguintes comandos:

git add new_file
git rm old_file

Se o conteúdo do arquivo for 50% ou mais semelhante, o git statuscomando running deve fornecer:

renamed: old_file -> new_file