Подготовка репозитория Windows Git для кроссплатформенной разработки

У меня есть репозиторий Git, который до сих пор в основном использовался для разработки Windows. Большинство аспектов проблем Git EOL (LF и CRLF) не были значительными, и разработка продолжалась беспрепятственно.
Перейдя в среду сборки CMake, я хочу собирать код на UNIX/Linux/MacOS. Сам код является переносимым, но, судя по прошлому опыту и некоторым первоначальным экспериментам, переход несколько болезненный, поскольку Git помечает целые каталоги в нетронутых файлах как измененные, обнаруживает кажущиеся неизмененными строки в файлах и искажает имена файлов/папок с учетом регистра.

Кроме того, кажется, что начиная с Git 1.7 .2, Git имеет новую систему EOL, основанную на локальном, для каждого проекта, зарегистрированном, .gitattributes вместо, для каждого пользователя, глобальном, .gitattributes, которое должно устанавливаться при каждом использовании на каждой платформе.

Может ли кто-нибудь предложить путь / процесс подготовки репо (в Windows), который позволит мне извлекать и фиксировать файлы в Linux без всех этих проблем?

Частичные предложения можно увидеть, например. здесь, но это слишком грубая сила и не учитывает файлы, которые .gitattributes специально намеревался оставить как есть (например, *.sln)


git cross-platform newline eol core.autocrlf
person Adi Shavit    schedule 25.10.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я использую Notepad2, с помощью которого вы можете изменить окончания строк по умолчанию на Linux (LF).

Если я правильно понимаю, нет реальной необходимости изменять исходные файлы, чтобы иметь LF на машинах Windows. Хотя Git регистрирует их с помощью LF, в Windows их можно извлечь с помощью CRLF.

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

person Steven Penny    schedule 08.12.2012
comment
К сожалению, это не всегда правильно. Некоторые текстовые файлы, например. написанные программным обеспечением, например .sln, .vc[x]proj и т. д., всегда должны иметь CRLF, а CRLF будет записываться в них обратно, благодаря чему они выглядят измененными при каждой регистрации. - person Adi Shavit; 10.12.2012

arrow_upward
0
arrow_downward

Как правило, не преобразовывайте данные автоматически перед их сохранением в системе контроля версий (autocrlf=false в git IIRC), иначе вы получите ложные срабатывания об изменении данных, хотя это не так. Оставьте любую «интерпретацию» того, что означают данные, инструментам за пределами VCS (редактор и т. д.).

Чтобы предотвратить ложные изменения новой строки, рассмотрите следующее:

  • Настройка какого-то хука перед коммитом, который отклоняет любые коммиты с изменениями, состоящими только из переписанных новых строк.
  • Защита только тех нескольких файлов, которые могут быть чувствительны к изменениям новой строки (файлы .sln, .vc* и т. д.).
  • Выясните, какие редакторы использует ваша команда, и убедитесь, что они у всех настроены так, чтобы они не переписывали символы новой строки. (Большинство редакторов уже настроены таким образом по умолчанию, так что у вас не будет проблем, пока кто-нибудь не возьмет на себя ответственность за то, чтобы их редактор переписал их.)
person Garen    schedule 19.08.2013