Лучший способ заставить Git закрывать глаза на мои изменения

Есть ли более чистый способ заставить Git просто игнорировать некоторые мои изменения и никогда их не фиксировать? .gitатрибуты:

config_to_be_deviated.xml filter=qqq

.git/конфиг:

[filter "qqq"]
 clean = "perl -ne 'print unless /git_please_dont_look_here/'"
 smudge = (Q=$(mktemp) && cat > $Q && patch -s $Q < /tmp/pp && cat $Q && rm $Q)

Патч /tmp/pp добавляет мои изменения с «git_please_dont_look_here» в каждой строке. Git удаляет все такие строки перед тем, как поместить файл в репозиторий, и считывает мои изменения при проверке; Я могу продолжать добавлять и фиксировать полезные изменения в config_to_be_deviated.xml, но изменения в патче не будут видны Git.


git filter config patch
person Vi.    schedule 12.02.2010    source источник
comment
Применение патча в обратном порядке на чистом — очевидное исправление и не считается ответом.   -  person Vi.    schedule 12.02.2010
comment
Можете ли вы рассказать нам, почему вы хотите быть в состоянии сделать это? кажется, что это противоречит тому, что должны делать git и большинство систем контроля версий...   -  person Charles Ma    schedule 12.02.2010
comment
Это может быть полезно, когда у вас другая среда сборки или есть жестко запрограммированные пути в файлах конфигурации в репозитории.   -  person Vi.    schedule 12.02.2010
comment
Еще один обходной путь, который я применял, заключался в том, чтобы делать коммиты с сообщением «Не совершать это в сообщении коммита» и использовать скрипт, который выполняет перебазирование, откат, нажатие и повторное применение, которое фиксирует.   -  person Vi.    schedule 12.02.2010
comment
Чувак, используй ветку. Все это конг-фу смешно.   -  person abyx    schedule 12.02.2010
comment
Не понимаю, чем ветка поможет. Изменения (отклонения) не должны когда-нибудь делиться или интегрироваться в проект. Они полностью как раз для меня. Примечание: это случай git-svn.   -  person Vi.    schedule 12.02.2010
comment
Желание иметь локальные конфигурации, которых нет в репозитории, вполне разумно. Играть в игры с git, чтобы это произошло. Это неправильный инструмент для работы, и какая-то часть вашего мозга тоже об этом знает, иначе вы бы не спрашивали, есть ли лучший способ. Есть, но на самом деле это не связано с git. Это включает в себя изменение места хранения вашей локальной конфигурации.   -  person Wayne Conrad    schedule 12.02.2010

Ответы (5)


arrow_upward
2
arrow_downward

Похоже, что этот подход «фильтр» лучше всего подходит для меня.

Плюсы:

  1. Нет необходимости каждый раз использовать пользовательские скрипты или специальные команды. Разовая установка.
  2. Никаких дополнительных коммитов в истории или в тайнике. Чистка дифов и патчей.
  3. Низкий риск совершения неправильного поступка.
  4. Относительно легко внести незначительные отклонения (например, переопределить какой-либо номер порта в файле конфигурации), например, простой скрипт sed как для размазывания, так и для очистки.

Минусы:

  1. Программы фильтрации запускаются каждый раз, когда Git читает или записывает файл, это может быть медленным (особенно в Windows).
person Vi.    schedule 12.02.2010

arrow_upward
1
arrow_downward

Поместить их в отдельный файл, игнорировать файл в git и подключить его к вашей сборке, чтобы он был включен?

person stefanB    schedule 12.02.2010
comment
подключить его к своей сборке -› не понял. Инструкции по его включению собьют с толку других разработчиков, особенно если у них нет файла моих отклонений. - person Vi.; 12.02.2010
comment
Все должно мешать отслеживаемому коду. Это просто изменения только у меня в каком-то файле, который также обновляется другими. - person Vi.; 12.02.2010
comment
@vi, поэтому создайте ветку local_conf и примените ее поверх ваших локальных изменений для тестирования. - person Benjamin Bannier; 12.02.2010
comment
Применить и отменить, а затем применить снова? Когда-нибудь я забуду отменить его и подтолкнуть ошибочное неверное изменение вверх по течению. /* Однажды я действительно совершил коммит Не совершайте этот коммит */ - person Vi.; 12.02.2010
comment
Нет. Например, мне это нужно было 1. отключить надоедливый плагин сбора статистики Maven в pom.xml, для успешной сборки которого требовалось сетевое подключение; 2. убрать заставку в разрабатываемом нами приложении; 3. добавить специализированный логгер, которым пользовался только я (и который тоже мог что-то сломать) - person Vi.; 12.02.2010

arrow_upward
1
arrow_downward

попробуй git update-index --assume-unchanged --<path>. Он действует как gitignore для файлов в системе контроля версий. Однако первоначальной целью этой функции было повышение производительности проверки модификаций git в папке с большим количеством файлов. Вот документ :

--предполагать-без изменений
--no-предполагать-без изменений

Когда эти флаги указаны, имена объектов, записанные для путей, не обновляются. Вместо этого эти параметры устанавливают и сбрасывают бит «предполагать неизменным» для путей. Когда установлен бит «предполагать неизменное», git прекращает проверку файлов рабочего дерева на наличие возможных модификаций, поэтому вам нужно вручную сбросить этот бит, чтобы сообщать git, когда вы изменяете файл рабочего дерева. Иногда это полезно при работе с большим проектом в файловой системе с очень медленным системным вызовом lstat(2) (например, cifs).

Этот параметр также можно использовать в качестве грубого механизма на уровне файлов для игнорирования незафиксированных изменений в отслеживаемых файлах (аналогично тому, что .gitignore делает для неотслеживаемых файлов). Вы должны помнить, что явная операция git add все равно приведет к обновлению файла из рабочего дерева. Git потерпит неудачу (изящно), если ему нужно изменить этот файл в индексе, например. при слиянии в коммит; таким образом, в случае изменения предполагаемого неотслеживаемого файла вверх по течению, вам придется обрабатывать ситуацию вручную.

person Igor Zevaka    schedule 12.02.2010
comment
Похоже на это 1. Добавляет необходимость использования пользовательских скриптов для фиксации/проверки. 2. Лишает меня возможности вносить полезные изменения в другие части файла. А что будет, если файл обновить вверх по течению? Похоже, оба варианта filter и Do not commit работают лучше. - person Vi.; 12.02.2010

arrow_upward
1
arrow_downward

  • Поместите каноническую конфигурацию по умолчанию в дерево git, но не играйте с ней в игры. Он находится в дереве, и если вы внесете в него изменения, они будут зафиксированы.
  • Программное обеспечение ищет конфигурацию по умолчанию, но также ищет конфигурацию в домашнем каталоге разработчика. Если он находит оба, он объединяет их. Любые элементы конфигурации, найденные в файле конфигурации разработчика, переопределяют элементы в файле конфигурации по умолчанию.

Теперь отслеживается конфигурация по умолчанию, а ваши настройки конфигурации по умолчанию — нет.

person Wayne Conrad    schedule 12.02.2010
comment
Все это означает, что я должен закоммитить в центральный репозиторий что-то, что не нужно другим разработчикам. Эти файлы вовсе не предназначены для редактирования штатными разработчиками. - person Vi.; 12.02.2010
comment
Почему этот файл вообще находится в исходном репозитории? Измените программное обеспечение, чтобы оно искало конфигурацию в вашем домашнем каталоге, и если вы хотите установить ее версию, создайте для нее отдельный репозиторий .git. - person Wayne Conrad; 12.02.2010
comment
Потому что это был файл, в котором говорилось, как должен быть собран проект (pom.xml). Не все разработчики знали его детали и редактировали их. - person Vi.; 12.02.2010
comment
Хорошо. Думаю, я знаю, на чем мы зациклились. Давайте попробуем что-нибудь еще (новый ответ выше). - person Wayne Conrad; 13.02.2010

arrow_upward
0
arrow_downward

Я не все знаком с git. В Mercurial я использую очередь исправлений (MQ) или полку (аналог git stash) для таких вещей.

git stash может быть удобно использовать, если вы «локализуемы», информацию легко найти (например, все в одном конфигурационном файле).

Использование очереди исправлений немного сложнее, но после правильной настройки лучше, потому что вы можете управлять локализуемой информацией прозрачным методом push/pop. Вы можете найти список очередей исправлений поверх git здесь, на SO.

person Johannes Rudolph    schedule 12.02.2010
comment
Я использую git stash для этой цели, если есть какие-то временные изменения, которые я не хочу фиксировать. В моем случае это постоянные изменения, которые я не хочу фиксировать. И я не хочу думать о девиантных файлах каждый раз, когда они изменяются или когда я что-то нажимаю. - person Vi.; 12.02.2010