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

Я использовал git update-index --assume-unchanged для некоторых файлов, чтобы мои изменения не были зафиксированы.

При использовании git stash в репозитории эти изменения сохраняются вместе с любыми другими выдающимися изменениями. Это ожидаемое поведение, однако git stash pop не возвращает их, поэтому изменения просто теряются.

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

Ответы

Ответ 1

Предположим, что неизменен взлом производительности, и представляет собой обещание от вас, что файл не изменился. Если вы действительно меняете файл, все ставки отключены. Вы должны либо перестроить свое репо, чтобы не передавать эти файлы (возможно, commit filename.sample и .gitignore filename), либо использовать трюки с ветвями, чтобы файлы, которые вы не хотите использовать совместно с остальным миром, отключены другая ветвь или иначе скрытая.

Я видел/думал о четырех предложениях о том, как скрыть эти изменения.

1: Используйте фильтр smudge/clean, чтобы изменить файл на то, что вы хотите, и очистите его при регистрации. Некрасиво.

2: Создайте ветвь локальной конфигурации, как описано в http://thomasrast.ch/git/local-config.html. Важно помнить, что вы развиваетесь на первичной ветке и слияние на ветку конфигурации для тестирования. Вернитесь к первичной ветке для изменения, нажмите и т.д.

3: Создайте ветку частного развития, сделайте изменение, которое вы никогда не хотите использовать совместно, а затем сделайте поддельное слияние (git merge -s ours privatebranch). Затем вы можете разрабатывать и тестировать в своем частном филиале, а изменение, которое вы не хотите использовать совместно, не должно быть, когда вы сливаетесь обратно, пока это изменение находится далеко от вашей обычной работы. Однако, когда вы получаете новые изменения от восходящего потока, вам нужно вытащить их непосредственно из ветки вверх по течению в частную ветку. Затем вы сливаетесь из частного назад в мастер и нажимаете вверх по течению от мастера. Вы никогда не должны сливаться с мастером на частную. Точно так же вы никогда не должны переустанавливать (ну, возможно, rebase -p будет работать, но никаких гарантий). Эти слияния /rebase и где каждый должен произойти, делает это менее привлекательным.

4: создайте ветку частного развития, сделайте изменение, которое вы никогда не хотите использовать совместно, а затем создайте драйвер слияния (см. man gitattributes), который откажется объединить файл, о котором идет речь, от мастера к частному или от частного к главному (возможно, путем сравнения SHA файла на частной ветке с различными ветвями SHA и копированием предыдущего значения, если оно соответствует).