так, а чо за фигня, на недобавленный файл разве нельзя сделать git add -p ? пишет no changes

add -p запустить на новом файле можно, но он всё-равно не позволяет его почему-то редактировать, так что это не имеет особого смысла

ну так да

Я сейчас нашёл более короткий ответ. Проблема, скорее, идеологическая — отслеживание файлов может помешать создать более гибкий и универсальный инструмент. Вот более удобный инструмент с которым в сложных ситуациях необходимость в отслеживании переименований становится более редкой, он, конечно, задокументирован, но то, какую проблему он решает стало понятно именно в контексте этой проблемы

Не понятно пока на практике, что удобнее — использовать его или добиться того, чтобы гит корректно определял переименование. Сейчас проверил на примере, когда файл был не переименован, а разбит на две части — это действительно удобно. Правда, при merge всё ещё напрочь это не помогает, лучше, наверное, использовать все доступные инструменты ¯\_(ツ)_/¯

.gitattributes вполне подошёл бы

в нем нет поддержки версий. это просто маппинг по именам файлов

ну вот,подходит же под изначальную хотелку:

> А для специфических случаев, где мы взывали git mv можно было бы и добавить метаданные, указывающие на переименование

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

ну короч так просто не сделать)

В гит не надо это тянуть, надо поверх гита реализовывать.
Вот пример решения для шифрования ключей, можно что-то такое реализовать поверх гита. https://buddy.works/guides/git-crypt

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

Однако, требование ручной пометки всех переименований вызывает очень большие проблемы у тулинга, и оказывает влияние на всю экосистему. Поэтому я лично считаю, что текущее решение, принятое в Гите — неплохой компромисс между сложностью и удобством.

только наверное адепты, а не оппоненты)

Всем привет

как найти все HEAD ревизии репозитория, которые имеют некоторый коммит предком?

У репозитория вроде только одна HEAD ревизия может быть. Вы имеете ввиду все ветки которые содержат коммит?

да. Наверное правильнее сказать "все ветки"

нашёл). Главное — правильно загуглить. git branch --contains <commit>

👍

Ну тогда ты по факту удаляешь файл и создаёшь другой. Всё логично

Привет, что значат символы между собаками в git diff
@@ -40,5 +40,5 @@ ? Я думал, что количество строк, но смотрю по VScode - не всегда совпадает.

Вот пример:

commit ab12f7e32d4e385a2990b3a29969baee373c6f42
Author:
Date:   Wed Jan 9 02:23:22 2019 +0300

    Fix #3453

diff --git a/main.go b/main.go
index 17e32af..bb99372 100644
--- a/main.go
+++ b/main.go
@@ -40,5 +40,5 @@ func main() {
 }
 
дальше строки, которые были добавлены

commit ab12f7e32d4e385a2990b3a29969baee373c6f42
Author:
Date:   Wed Jan 9 02:23:22 2019 +0300

    Fix #3453

diff --git a/main.go b/main.go
index 17e32af..bb99372 100644
--- a/main.go
+++ b/main.go
@@ -40,5 +40,5 @@ func main() {
 }
 
дальше строки, которые были добавлены

это кусок вывода

git log -p