Как сделать так, чтобы git пометил удаленный и новый файл как файл перемещенный?

Question

Я переместил файл вручную, а затем изменил его. По словам Git, это новый файл и удаленный файл. Есть ли способ заставить Git рассматривать его как перемещение файла?

Answer 1

Git автоматически обнаружит движение / переименование, если ваша модификация не слишком серьезна. Просто git add новый файл и git rm старый файл. git status покажет, обнаружил ли переименование.

Кроме того, для перемещения по каталогам может потребоваться:

1. перейдите к началу этой структуры каталогов.
2. Пробег git add -A .
3. Запустите git status, чтобы убедиться, что «новый файл» теперь является «переименованным» файлом

Если в статусе git по-прежнему отображается «новый файл», а не «переименован», вам нужно следовать совету Хэнка Гея , а также перемещать и изменять в двух отдельных коммитах.

Answer 2

Выполните перемещение и модификацию в отдельных коммитах.

Answer 3

Это всё воспринимаемое. Git обычно довольно хорошо распознает ходы, потому что GIT является трекером контента

Все, что действительно зависит, - это то, как ваша «статистика» отображает это. Единственная разница здесь - флаг -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.

Answer 4

git diff -M или git log -M должны автоматически обнаруживать такие изменения, как переименование с незначительными изменениями , если они действительно есть. Если ваши незначительные изменения не являются незначительными, вы можете уменьшить порог сходства, например,

$ git log -M20 -p --stat

чтобы уменьшить значение по умолчанию с 50% до 20%.

Answer 5

Вот быстрое и грязное решение для одного или нескольких переименованных и измененных файлов, которые не были переданы.

Допустим, файл назывался foo, а теперь он называется bar:

1. Переименуйте bar во временное имя:

   mv bar side
   

2. Оформить заказ foo:

   git checkout HEAD foo
   

3. Переименуйте foo в bar с помощью Git:

   git mv foo bar
   

4. Теперь переименуйте ваш временный файл обратно в bar.

   mv side bar
   

Этот последний шаг - то, что возвращает измененный контент обратно в файл.

Хотя это может сработать, если перемещенный файл слишком отличается по содержанию от исходного git, он посчитает более эффективным определить, что это новый объект. Позвольте мне продемонстрировать:

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

Answer 6

Если вы говорите, что git status не показывает переименования, попробуйте git commit --dry-run -a вместо

Answer 7

Если вы используете TortoiseGit, важно отметить, что автоматическое обнаружение переименования в Git происходит во время коммита, но тот факт, что это произойдет, не всегда отображается программным обеспечением заранее. Я переместил два файла в другой каталог и выполнил несколько небольших изменений. Я использую TortoiseGit в качестве инструмента фиксации, и в списке «Изменения» были показаны файлы, которые были удалены и добавлены, а не перемещены. Запуск git status из командной строки показал похожую ситуацию. Однако после фиксации файлов они оказались переименованы в журнале. Таким образом, ответ на ваш вопрос таков: если вы не сделали ничего слишком радикального, Git должен автоматически переименовать его.

Редактировать: очевидно, если вы добавляете новые файлы, а затем делаете состояние git из командной строки, переименование должно отображаться перед фиксацией.

Редактировать 2: Кроме того, в TortoiseGit добавляйте новые файлы в диалоге фиксации, но не фиксируйте их. Затем, если вы войдете в команду Show Log и посмотрите на рабочий каталог, вы увидите, обнаружил ли Git переименование перед фиксацией.

Тот же вопрос был поднят здесь: https://tortoisegit.org/issue/1389 и был зарегистрирован как ошибка, чтобы исправить здесь: https://tortoisegit.org/issue/1440 Оказывается, это проблема с отображением в диалоге фиксации TortoiseGit, а также существует git status, если вы не добавили новые файлы.

Answer 8

Или вы можете попробовать ответить на этот вопрос здесь с Янтарь ! Чтобы процитировать это снова:

Сначала отмените поэтапное добавление для перемещенного вручную файла:

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

Затем используйте Git для перемещения файла:

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

Конечно, если вы уже совершили ручное перемещение, вы можете вместо этого сбросить его до ревизии, а затем просто выполнить git mv.

Answer 9

У меня была эта проблема недавно, при перемещении (но не изменении) некоторых файлов.

Проблема в том, что Git изменил некоторые окончания строк, когда я переместил файлы, а затем не смог сказать, что файлы были одинаковыми.

Использование git mv решило проблему, но она работает только для отдельных файлов / каталогов, и у меня было много файлов в корне хранилища.

Один из способов исправить это - использовать магию bash / batch.

Другой способ заключается в следующем

• Переместите файлы и git commit. Это обновляет окончания строки.
• Переместите файлы обратно в их исходное местоположение, теперь, когда у них новые окончания строк, и git commit --amend
• Переместите файлы еще раз и git commit --amend. В этот раз нет изменений в конце строки, поэтому Git счастлив

Answer 10

Используйте команду git mv для перемещения файлов вместо команд перемещения ОС: https://git -scm.com / документы / ГИТ-мв

Обратите внимание, что команда git mv существует только в Git версий 1.8.5 и выше. Поэтому вам, возможно, придется обновить ваш Git, чтобы использовать эту команду.