Jak sprawić, aby git oznaczył usunięty i nowy plik jako przeniesienie pliku?

Przeniesiłem plik ręcznie, a następnie zmodyfikowałem go. Według Git jest to nowy plik i plik usunięty. Czy jest jakiś sposób, aby zmusić Gita do traktowania go jako przeniesienia pliku?

Git automatycznie wykryje przeniesienie / zmianę nazwy, jeśli modyfikacja nie jest zbyt poważna. Tylko git addnowy plik i git rmstary plik. git statuspokaże wtedy, czy wykrył zmianę nazwy.

dodatkowo w przypadku przemieszczania się po katalogach może być konieczne:

1. cd na początek tej struktury katalogów.
2. Biegać git add -A .
3. Uruchom, git statusaby sprawdzić, czy „nowy plik” jest teraz plikiem o zmienionej nazwie

Jeśli status git nadal pokazuje „nowy plik”, a nie „przemianowano”, musisz postępować zgodnie z radą Hanka Gaya, wykonać ruch i zmodyfikować w dwóch osobnych zatwierdzeniach.

Wykonaj ruch i modyfikuj w osobnych zatwierdzeniach.

To wszystko jest kwestią percepcyjną. Git jest ogólnie dość dobry w rozpoznawaniu ruchów, ponieważ GIT jest narzędziem do śledzenia zawartości

Wszystko, co tak naprawdę zależy, to sposób, w jaki wyświetla się „stat”. Jedyną różnicą jest tutaj flaga -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 -Mlub git log -Mpowinien automatycznie wykryć takie zmiany jako zmianę nazwy z niewielkimi zmianami, o ile rzeczywiście są. Jeśli Twoje drobne zmiany nie są niewielkie, możesz zmniejszyć trzykrotne podobieństwo, np

$ git log -M20 -p --stat

zmniejszyć go z domyślnych 50% do 20%.

Oto szybkie i brudne rozwiązanie dla jednego lub kilku plików o zmienionej nazwie i zmodyfikowanych, które nie zostały zatwierdzone.

Powiedzmy, że plik został nazwany, fooa teraz nazywa się bar:

1. Zmień nazwę barna tymczasową nazwę:

   mv bar side
   

2. Zamówienie foo:

   git checkout HEAD foo
   

3. Zmień nazwę foona barGit:

   git mv foo bar
   

4. Teraz zmień nazwę pliku tymczasowego z powrotem na bar.

   mv side bar
   

Ten ostatni krok przywraca zmienioną zawartość do pliku.

Chociaż może to zadziałać, jeśli przeniesiony plik ma zbyt inną zawartość niż oryginalny git, uzna, że ​​skuteczniej jest zdecydować, że jest to nowy obiekt. Pokażę:

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

Jeśli mówisz o git statusnie pokazywaniu nazw, spróbuj git commit --dry-run -azamiast tego

Jeśli używasz TortoiseGit, ważne jest, aby pamiętać, że automatyczne wykrywanie zmiany nazwy Gita ma miejsce podczas zatwierdzania, ale fakt, że tak się stanie, nie zawsze jest wcześniej wyświetlany przez oprogramowanie. Przeniosłem dwa pliki do innego katalogu i dokonałem niewielkich zmian. Używam TortoiseGit jako mojego narzędzia do zatwierdzania, a lista wprowadzonych zmian pokazała, że ​​pliki są usuwane i dodawane, a nie przenoszone. Uruchomienie statusu git z wiersza poleceń pokazało podobną sytuację. Jednak po zatwierdzeniu plików pojawiły się w dzienniku jako przemianowane. Tak więc odpowiedź na twoje pytanie jest taka, o ile nie zrobiłeś nic zbyt drastycznego, Git powinien automatycznie zmienić nazwę.

Edycja: Najwyraźniej jeśli dodasz nowe pliki, a następnie wykonasz status git z wiersza poleceń, zmiana nazwy powinna pojawić się przed zatwierdzeniem.

Edycja 2: Ponadto, w TortoiseGit, dodaj nowe pliki w oknie dialogowym zatwierdzenia, ale ich nie zatwierdzaj. Następnie, jeśli przejdziesz do polecenia Pokaż dziennik i spojrzysz na katalog roboczy, zobaczysz, czy Git wykrył zmianę nazwy przed zatwierdzeniem.

To samo pytanie zostało zadane tutaj: https://tortoisegit.org/issue/1389 i zostało zarejestrowane jako błąd do naprawy tutaj: https://tortoisegit.org/issue/1440 Okazuje się, że jest to problem z wyświetlaniem w zatwierdzeniu TortoiseGit dialog, a także istnieje w stanie git, jeśli nie dodałeś nowych plików.

Albo możesz spróbować odpowiedzieć na to pytanie tutaj przez Amber ! Cytując to jeszcze raz:

Najpierw anuluj dodawanie etapowe dla ręcznie przeniesionego pliku:

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

Następnie użyj Git, aby przenieść plik:

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

Oczywiście, jeśli już dokonałeś ręcznego przenoszenia, możesz zamiast tego zresetować wersję przed przeniesieniem, a następnie po prostu pobrać stamtąd mv.

Użyj git mvpolecenia, aby przenieść pliki, zamiast poleceń przenoszenia systemu operacyjnego: https://git-scm.com/docs/git-mv

Pamiętaj, że git mvpolecenie istnieje tylko w Git w wersji 1.8.5 i nowszych. Może być konieczne zaktualizowanie Gita, aby użyć tego polecenia.

Ostatnio miałem ten problem podczas przenoszenia (ale nie modyfikowania) niektórych plików.

Problem polega na tym, że Git zmienił niektóre zakończenia linii, gdy przenosiłem pliki, a następnie nie był w stanie stwierdzić, że pliki były takie same.

Korzystanie git mvz rozwiązania problemu, ale działa tylko na pojedyncze pliki / katalogi, a ja miałem wiele plików w katalogu głównym repozytorium do zrobienia.

Jednym ze sposobów naprawienia tego byłoby użycie magii typu bash / batch.

Inny sposób jest następujący

• Przenieś pliki i git commit. To aktualizuje zakończenia linii.
• Przenieś pliki z powrotem do ich oryginalnej lokalizacji, teraz, gdy mają nowe zakończenia linii i git commit --amend
• Przenieś pliki ponownie i git commit --amend. Tym razem nie ma zmian w zakończeniach linii, więc Git jest szczęśliwy

Dla mnie zadziałało przechowywanie wszystkich zmian przed zatwierdzeniem i wyskakiwanie ich ponownie. To spowodowało, że git ponownie przeanalizował dodane / usunięte pliki i poprawnie oznaczył je jako przeniesione.

Jest na to prawdopodobnie lepszy sposób „wiersza poleceń” i wiem, że to hack, ale nigdy nie byłem w stanie znaleźć dobrego rozwiązania.

Korzystanie z TortoiseGIT: Jeśli masz zatwierdzenie GIT, w którym niektóre operacje przenoszenia plików są wyświetlane jako ładunek dodawania / usuwania zamiast zmiany nazw, nawet jeśli pliki mają tylko niewielkie zmiany, wykonaj następujące czynności:

1. Sprawdź, co zrobiłeś lokalnie
2. Sprawdź zmianę mini-liniową w drugim zatwierdzeniu
3. Idź do GIT zaloguj się żółw git
4. Wybierz dwa zatwierdzenia, kliknij prawym przyciskiem myszy i wybierz „scal w jeden zatwierdzenie”

Nowe zatwierdzenie będzie teraz poprawnie wyświetlało nazwy plików… co pomoże utrzymać właściwą historię plików.

Kiedy jednocześnie edytuję, zmieniam nazwę i przenoszę plik, żadne z tych rozwiązań nie działa. Rozwiązaniem jest zrobienie tego w dwóch zatwierdzeniach (edycja i zmiana nazwy / przeniesienie osobno), a następnie fixupw drugim zatwierdzeniu za pomocą git rebase -ijednego zatwierdzenia.

Rozumiem to pytanie: „Jak sprawić, aby git rozpoznał usunięcie starego pliku i utworzenie nowego pliku jako przeniesienie pliku”.

Tak w katalogu roboczym po usunięciu starego pliku i wstawieniu starego pliku, git statuspowie „ deleted: old_file” i „ Untracked files: ... new_file”

Ale w indeksie pomostowym / poziomie po dodaniu i usunięciu pliku za pomocą git zostanie rozpoznany jako przeniesienie pliku. Aby to zrobić, zakładając, że wykonałeś usuwanie i tworzenie za pomocą swojego systemu operacyjnego, podaj następujące polecenia:

git add new_file
git rm old_file

Jeśli zawartość pliku jest w 50% lub więcej podobna, uruchomiona git statuskomenda powinna dać ci:

renamed: old_file -> new_file