Как зафиксировать переименование файла и редактирование его содержимого отдельно (чтобы git обнаружил переименование)?

Question

Когда я уточняю код, я переименовываю и редактирую файл настолько , что git не распознает его как переименованное.

Исправлено: зафиксировать переименование старого файла; затем передайте новый файл.

Как я могу сделать это красиво с git, после всего редактирования?

---

git stash не распознает новое имя файла.

В настоящее время я делаю это:

• переместить новый файл в другое место - git reset oldfile чтобы получить старый файл
• переименуйте его

• совершить это

• Теперь верните новый файл, перезаписав вышеуказанное

• совершить это

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

Кажется, просто . Что-то вроде того, с чем мог бы помочь мерзавец ...

РЕДАКТИРОВАТЬ Я могу передать его во временную ветку, для reflog безопасности.

Answer 1

Git не предоставляет действительно хороший способ сделать это, но это работает.Допущения:

• foo - это старое имя файла, а имя, которое измененный файл все еще имеет на диске
• bar - это новое имя, которое вы хотите иметь
• Не внесены изменения в индекс

Затем выполните:

git update-index --add --cacheinfo "$(git ls-files --full-name -s foo \
    | awk '{print $1 "," $2 ",bar"}')"
git rm --cached foo
git commit -m "rename foo to bar"
mv foo bar
git add bar
git commit -m "make changes to bar"

git update-index указывает git подготовить новый файл в индексе с помощьютот же хеш и режим, что и в индексированной версии foo, но с новым именем bar.Он не обращается к диску, он просто предполагает, что объект существует с этим хешем (что он и делает).git rm --cached указывает git выполнить удаление foo, не касаясь диска.Вместе они составляют переименование, которое мы можем совершить.Затем мы перемещаем файл по-настоящему, используем git add, чтобы сообщить git о его новом содержимом, и фиксируем снова.Естественно, вы также можете добавить другие изменения в этот коммит.

между git update-index и mv, git status покажет не поэтапное изменение deleted: bar, поскольку файл существует в индексено не на диске (по крайней мере, пока не под этим именем), но это не проблема.

Обратите внимание, что имя bar должно быть путем относительно корня хранилища, даже есливы работаете из подкаталога.Для простоты работайте из корня репо и используйте полный путь как для foo, так и для bar.

Ничто из этого не на проще , чем то, что вы делаете, но этоизбегает необходимости отменять изменения из вашего рабочего дерева.

Answer 2

Я думаю, это будет звучать упрощенно, но самое простое решение: когда вы редактируете файл, и у вас есть куча ожидающих изменений, и вы решаете, что файл должен быть переименован,

(1) запишите, что вам нужно переименовать его (2) вернуть файл в состояние, в котором вы можете зафиксировать изменения, которые у вас есть (3) совершить это (4) переименовать его (5) совершить переименование (6) при необходимости продолжить редактирование

То есть - если вы не хотите фиксировать переименование в то же время, когда вы вносите изменения в затронутый файл ... тогда не делайте.

В очень немногих случаях может быть причина совершить переименование с изменением. Например, общедоступное имя класса в Java должно соответствовать его имени файла. Но это нормально - порог изменения при обнаружении переименования в любом случае не соответствует (по умолчанию) 100%. Небольшие изменения редко навредят чему-либо. Но это не совсем проблема, потому что вы уже решили, что хотите сделать отдельные коммиты.

Таким образом, проблема заключается лишь в небольшом планировании. В тот момент, когда вы собираетесь переименовать значительно отредактированный файл (или значительно отредактировать переименованный файл), это момент, когда нужно решить: «О, я хочу отделить этот следующий шаг в другом коммите от того, что я уже сделал ».

Если вы действительно не можете этого сделать, тогда тайник на самом деле хорошо. Храните свои правки, переименовывайте файл, фиксируйте, извлекайте тайник. Да, извлеченный файл будет по неправильному пути, поэтому переименуйте его снова (перезаписав оригинал).

Между прочим, в зависимости от вашего рабочего процесса это может быть напрасным. Слияние не будет смотреть на отдельные коммиты и будет видеть точно такую ​​же ситуацию, как если бы вы сделали все за один коммит. Если вы используете рабочий процесс, основанный на ребазе, вы можете обнаружить, что он действительно помогает (хотя это имеет и другие затраты). Но в целом я бы сказал, что есть и другие стратегии, которые делают больше для решения этой проблемы - например, обеспечить кратковременное расхождение ветвей, чтобы свести к минимуму разрешение конфликтов даже в том случае, если обнаружение переименования оказалось неудачным.