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

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

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

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

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

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

Делать движение и модифицировать в отдельных коммитах.

Это все воспринимаемые вещи. 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.

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

$ git log -M20 -p --stat

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

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

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

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

   mv bar side
   

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

   git checkout HEAD foo
   

3. Переименуйте fooв barGit:

   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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для меня это сработало, чтобы сохранить все изменения перед фиксацией и вытащить их снова. Это заставило git повторно проанализировать добавленные / удаленные файлы и правильно пометить их как перемещенные.

Существует, вероятно, лучший способ «командной строки» сделать это, и я знаю, что это взлом, но я так и не смог найти хорошего решения.

Использование TortoiseGIT: Если у вас есть коммит GIT, в котором некоторые операции перемещения файлов отображаются в виде загрузки / удаления, а не переименования, даже если файлы имеют небольшие изменения, сделайте следующее:

1. Проверьте, что вы сделали локально
2. Проверить мини-однострочное изменение во 2-м коммите
3. Перейти в GIT войти в черепаху Git
4. Выберите два коммита, щелкните правой кнопкой мыши и выберите «объединить в один коммит»

Новый коммит теперь будет правильно отображать переименования файлов ..., что поможет поддерживать правильную историю файлов.

Когда я редактирую, переименовываю и перемещаю файл одновременно, ни одно из этих решений не работает. Решение состоит в том, чтобы сделать это в двух коммитах (редактировать и переименовать / переместить по отдельности), а затем fixupчерез второй коммит git rebase -iсделать это в одном коммите.

Как я понимаю этот вопрос: «Как заставить git распознавать удаление старого файла и создание нового файла при перемещении файла».

Да, в рабочем каталоге, как только вы удалите старый файл и вставите старый файл, git statusпроизойдет " deleted: old_file" и " Untracked files: ... new_file"

Но в промежуточном индексе / уровне, когда вы добавляете и удаляете файл с помощью git, он будет распознаваться как перемещение файла. Для этого, если вы выполнили удаление и создание с помощью своей операционной системы, введите следующие команды:

git add new_file
git rm old_file

Если содержимое файла на 50% или более одинаковое, при выполнении git statusкоманды вы должны получить:

renamed: old_file -> new_file