Как игнорировать изменения файлового режима в Git после разрешения конфликта?

Question

Я серьезно собираюсь перестать кодировать и стать плотником.Эта проблема заставляла меня напрягаться в течение достаточно долгого времени, и, похоже, не существует какого-либо ясного решения, кроме того, что принуждение компьютеров, не являющихся Windows, использовать права доступа к файлам, по-видимому, вызывает.

Давайте начнем ссценарий.У меня есть 2 машины для разработки, одна под управлением Windows7, другая под Mac OSX.Они оба используют Eclipse и EGit, и оба клонировали один и тот же проект из удаленного репозитория.На этом сходство заканчивается, потому что у моей машины с Windows есть неприятная привычка сохранять файловый режим 644 (r-xr - r--) в локальном репо, в то время как режим на Mac по умолчанию равенкруто 775 (rwxrwxr - x).

Так что проблема, очевидно, в правах доступа к файлам - GIT сообщает, что есть файлы, которые изменились из-за различий в режимах файлов, а не из-за фактического содержимого.Решение казалось очевидным, запустив следующие команды:

 git config core.filemode false
 git config --global core.filemode false

... который работал как шарм, за исключением , когда фиксация и объединение разрешали конфликты .

Например, скажем, файлы A, B и C существуют в репозиториях Windows и Mac.Теперь давайте изменим режим файлов для этих 3 файлов на компьютере Mac, чтобы разработчик мог их редактировать.Теперь измените часть содержимого в файле A. Поскольку мы игнорируем режимы файлов (благодаря приведенным выше командам), только файл A будет зафиксирован и передан, готов для машины Windows, чтобы получать, объединять и наслаждаться ...

Теперь, давайте снова отредактируем файл A на Mac и на компьютерах с Windows, эффективно вызывая потенциальный конфликт, и пусть машина с Windows фиксирует и загружает файл A первым.Затем, когда пользователь Mac фиксирует свои изменения в файле A и извлекает последние изменения из удаленного репозитория, очевидно, создается конфликт.

После разрешения конфликта на компьютере Mac и добавления файла A обратно в его локальныйрепо, фиксация этого слияния включает в себя ранее проигнорированные файлы B и C, что подчеркивает мою проблему!Почему ранее игнорируемые файлы включены в этот коммит слияния?Кажется, это не проблема исключительно Mac / Windows, поскольку эту проблему можно воссоздать в обоих направлениях ...

Это, вероятно, не имеет значения, если бы было только 3 файла, но этот проект яупоминание включает в себя тысячи, и все эти взлеты и падения безумны.Я что-то упускаю действительно очевидное?Любая помощь будет принята с благодарностью!

Answer 1

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

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

, что должно быть ошибкой вgit, что еще это может быть?

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

правильный ответ заключается в том, что git не используетfilemode, когда ему сказано не делать этого, он явно игнорирует это и делает это в любом случае.

Вы можете объяснить иначе.

Answer 2

Таким образом, после долгого и часто разочаровывающего попытки попытаться заставить машины Windows и Mac OS нравиться друг другу при сравнении заметок и изменений в Git, кажется, что только функциональность самого Git привела меня в бешенство, и лучше Понимание того, как лучше использовать Git, кажется окончательным ответом.

Изначально я хотел знать, как продолжать игнорировать изменения в файловом режиме (которые Windows, похоже, любила обновлять с собственным представлением о том, какими должны быть разрешения и режимы), пока я разрешал конфликты, созданные из-за обновлений файлов от кого-то другого. , Краткий ответ: вы не можете . Так работает Git.

Так как бы вы справились с этой ситуацией, когда она возникла? Короткий ответ снова: используйте ветвление .

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

С помощью ветвления вы работаете с другой веткой, фиксируете эту ветку, извлекаете обновления в свою основную ветку и объединяете другую ветку с вашей главной веткой после этого. Вдруг больше нет конфликтов на мастера из удаленного репо, и вы выигрываете!

Команды для этого (создание ветви из текущей выбранной ветви):

git branch newbranch

Чтобы оформить заказ в новом филиале:

git checkout newbranch

Чтобы объединить вашу новую ветку с вашей главной веткой (после того, как вы подтвердите свой newbranch, сначала переключитесь на основную ветку):

git checkout master
git merge newbranch

Надеюсь, это кому-нибудь поможет! -:)