мерзкие пробелы

Question

Конфликты на пустом месте сосут

Пробел оказался ужасной болью для меня при использовании git.

git config apply.whitespace=strip

кажется, увеличивает ваши шансы на конфликты (когда вы раздеваетесь ненужные пробелы, а затем другие сотрудники видят раздели пробелы как изменение их коммитов?)

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

Я хочу разрешить конфликты пробелов без предупреждения:

Я никогда не хочу иметь другой конфликт на пустом месте. Если другой коммиттер изменяет пробел, или я изменяю пробел, а затем должен слиться с моими собственными конфликтами, я действительно не хочу об этом знать . Если кто-то изменит мой код с стиля K & R на стиль One True Brace, изменяя пробел, я бы предпочел, чтобы git позволил любой установке пробелов победить необходимость увидеть конфликты по этому поводу. Мне просто наплевать на пробелы, чтобы хотеть увидеть конфликты по этому поводу.

Итак ... ... есть ли способ настроить git для этого?

Если это имеет какое-то значение, вот моя версия git и мой текущий конфигурации:

tchalvak:~/ninjawars$ git --version
git version 1.6.0.4

tchalvak:~/ninjawars$
git config --list
color.branch=auto
color.diff=auto
color.status=auto
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red bold
color.diff.new=green bold
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
gui.recentrepo=/home/tchalvak/zd/htdocs/cms
apply.whitespace=strip
user.name=****
user.email=****
alias.co=checkout
github.user=tchalvak
github.token=****
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=...@github.com:tchalvak/ninjawars.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master 

Answer 1

Git1.6.0.4 кажется немного старым, особенно если учесть, что:

• in 1.6.3.4 , "git apply --whitespace=fix" не исправил конечные пробелы в неполная строка
• in 1.6.3.2 , установленный атрибут "whitespace" предназначался для обнаружения всех известных ошибок Git, но он сказал Git игнорировать завершающие возврат каретки.

Не могли бы вы попробовать с Git1.6.4.1, и вместо того, чтобы устанавливать глобальную конфигурацию, установите для файлов, для которых вы хотите, специальный дескриптор пробела, как этот патч описывает .

В данном каталоге создайте файл .gitattributes.

* -whitespace

, который будет игнорировать любые «пробельные» ошибки.

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

---

Патч был тестом о:

Игнорировать только пробельные ошибки в t/tNNNN-*.sh и t/tNNNN подкаталогах.
Другие файлы (например, тестовые библиотеки) все еще должны быть проверены.

t/.gitattributes
t[0-9][0-9][0-9][0-9]-*.sh  -whitespace
t[0-9][0-9][0-9][0-9]/*     -whitespace

---

Примечание (Git 2.3.2+, первый квартал 2015 года, commit 0a80bc9 , от Junio ​​C Hamano aka gitster) "git apply --whitespace=fix" больше не молчит:

"git apply --whitespace=fix" исправлены пробельные ошибки в общем контекстные строки, но сделали это без отчетов.

Если во входящем патче есть ошибки пробела в строке общего контекста (т. Е. Строка, которая, как ожидается, будет найдена и не изменена патчем), "apply --whitespace=fix" исправляет ошибки пробела, которые есть в строке, в дополнение к ошибка пробела в строке, которая обновляется патчем.
Однако мы не учитывали и не сообщали о том, что исправили ошибки с пробелами в таких строках.

Answer 2

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