есть винда
и есть такой чудесный репозиторий под линукс https://github.com/sipwise/rtpengine.git

хочется мониторить его на винде
но вот проблема
репа содержит файлы aux.c aux.h которые не переваривает винда
и сделать pull невозможно, как и checkout

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

казалось бы проблему можно было решить каким нибудь checkout force который бы поскипал файлы которые не может записать
но гребаный git(привет тупой линус) этого не умеет

когда то давно я делал чекаут каждого отдельного файла который изменятся кроме тех aux.*
но это накладно
пытался придумать какие то merge итд где переименовал эти aux и что бы держать отдельную свою ветку в той же репе
но опять же ничего не срабатывало

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

Здравствуйте, reversecode, Вы писали:

R>хочется мониторить его на винде
R>но вот проблема
R>репа содержит файлы aux.c aux.h которые не переваривает винда

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

может на 10 или 11 винде и пофиксили
но даже у рара на 7 проблемы

Здравствуйте, reversecode, Вы писали:

R>может на 10 или 11 винде и пофиксили
R>но даже у рара на 7 проблемы
R>Image: gitaux.png

Это работало ещё в вин2000, и на вин7 замечательно работает в Far Manager. Просто авторы RAR'а, как и некоторых других программ, они в некотором роде ушлёпки. Например, они любят пользоваться классическими сокетами, которые bind/listen/select/accept, хотя этому интерфейсу уже под 40 лет и давно уже имеется новое, менее тормозное, не требующее блокировки и выделенного потока.

Здравствуйте, Слава, Вы писали:

R>>репа содержит файлы aux.c aux.h которые не переваривает винда
С>Винда эти файлы умеет. И всегда умела. Это у авторов гита удивительно кривые руки. Возьмите какой-нибудь альтернативный клиент git. Но я сомневаюсь, что даже у штатного гита с этими файлами проблема.

Сейчас в Windows 8.1 попробовал создать файл, не получилось, причём проблема создать даже aux. В интернетах пишут, что это наследие ещё от DOS. И не просто зарезервированные имена, а зарезервированные начала имён. Выглядит это конечно крайне глупо. Как всегда, говноделы из майкрософт создали проблемы, а виноваты все остальные.

на ночь глядя могу предположить что это наследие сидит в msvcrt
которые фар обходит
но проблемы это не решает
алтернативных адекватных клиентов нет
те что есть все юзают mingw и там все плохо

поэтому хочется каких то солюшинов с самим гитом

и не парься.

Ну или если очень хочется, можно попробовать сделать checkout в \\?\c:\full\path, что отключит обработку всяких aux и прочих lpt13, но с WSL будет проще.

Здравствуйте, Слава, Вы писали:

С>Это работало ещё в вин2000, и на вин7 замечательно работает в Far Manager. Просто авторы RAR'а, как и некоторых других программ, они в некотором роде ушлёпки.

А что твоя экспертиза говорит о type в cmd или об Explorer?

Здравствуйте, reversecode, Вы писали:

R>...

Проблема в Windows и только в ней.

* У меня git, портированный под Cygwin, успешно сделал checkout, так как Cygwin транслирует пути на промежуточном уровне.
* Как вариант: заскриптовать plumbing-команды типа git-ls-tree для обхода дерева и вычитывать нужное содержимое с помощью git-cat-file в bare-репозитории, периодически делая git-fetch.
* Или использовать tig или его аналоги, позволяющие видеть содержимое блобов.
* Или как-то заставить работать git-archive для bare-репозиториев с последующей распаковкой инструментом, умеющим открывать/извлекать файлы с такими именами (тем же 7-Zip или Far Manager). У меня не получилось с git-archive под Windows-реализацию, потому как git начал ругаться на aux в имени daemon/aux.c, причём для всех поддерживаемых форматов архивов (логично предположить, что этого ограничения при чтении базы данных содержимого репозитория быть не должно, так как и git-ls-tree и git-cat-file работают). + Напрямую git-archive с ключом --remote не поддерживается GitHub.

С git-checkout дела, по ходу, плохи.

да я готов пожертвовать теми aux файлами
черт с ними

но нет же никакого checkout force что бы оно пропустило их и вытянуло все остальные

Здравствуйте, reversecode, Вы писали:

R>но нет же никакого checkout force что бы оно пропустило их и вытянуло все остальные

Думаю, в архивах рассылок разработчиков git можно найти, почему условный "--ignore-invalid-names" не реализован в git-checkout. Хотя, мне кажется, этой возможностью лучше было бы управлять из конфигов, где-то из условного "core.invalidNamesResolveStrategy", принимающего значения abort, ignore, rename и т.д. (хотя это не симметрично относительно к тому же core.ignoreCase). Похожей опции не нашёл. Можно попробовать реализовать самому.

Здравствуйте, reversecode, Вы писали:

R>есть винда
Сочувствую...
А sparse checkout помог?

printf >.git/info/sparse-checkout %s\\n \
        '*' '!'{con,prn,aux,nul,lpt[1-9],com[1-9]}{,'.*'} 
git config core.sparsecheckout true

https://stackoverflow.com/questions/60696004/tell-git-pull-to-ignore-a-file-named-con-dat-since-it-cant-be-checked-out-on-wi

Здравствуйте, halo, Вы писали:

H> А что твоя экспертиза говорит о type в cmd или об Explorer?

Тоже ушлёпки. Своим собственным winapi пользоваться не умеют.

sparse не помог от слова совсем
есть подозрение или он сломан в моей гит версии (git version 2.34.0.windows.1)
или там что то с масками sparse-checkout файлов накручено

но помог

[core]
protectNTFS = false

и reset hard origin
и git pull
все теперь вроде работает

Здравствуйте, Слава, Вы писали:

R>>репа содержит файлы aux.c aux.h которые не переваривает винда
С>Винда эти файлы умеет. И всегда умела.

1. Не всегда. На MSDN уже мало истории, но помнится, что средство обхода таких проблем появилось не то в 2000+XP, не то в XP+2003.

2.Прямо сейчас в актуальных версиях статей:

Do not use the following reserved names for the name of a file:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces.

Тут.

"Do not use", которое немедленно не сопровождается "а чтобы не было проблем, используйте вначале \\?\", прямо говорит, что такое недопустимо. Я не думаю, что это следует читать как-то иначе.

3. С учётом по той же ссылке запрета наличия в именах файлов всяких : | ? * и т.п., которые совершенно законно могут быть в юниксовых путях и в их гитовом отображении — зачем специально заботиться со стороны именно движка про aux.c? Авторы Git возложили это на волю админов и коммиттеров конкретных реп, и IMO правильно сделали. Все собственные средства Git не создают плохих имён, и этого им достаточно.

C> Это у авторов гита удивительно кривые руки.

Или они просто честно читают, что им рекомендует сама Microsoft.

Я, кстати, внимательно перечитал статью по ссылке и попытался найти, как же создавать такие имена файлов, только по документации, без экспериментов. То, что вижу:

1) Это явно нигде не сказано. Рядом есть пассаж:

Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.

Many but not all file I/O APIs support "\\?\"; you should look at the reference topic for each API to be sure.

То есть типа есть намёк на то, что \\?\ позволяет работать с таким (за счёт turns off automatic expansion и ссылки на Namespaces в первой цитате), но точных данных нет. И при этом всё равно не все API такое умеют.

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

Если он не выполняет всё это извращение по перепаковке в абсолютный путь и добавлению префикса для не-разбора путей — то да, согласно этой статье будет проблема.

Что же до резервированных имён, я удивляюсь, что это до сих пор не отключили. По-нормальному это надо было сделать ещё в семёрке, если не раньше.

Здравствуйте, velkin, Вы писали:

V>Сейчас в Windows 8.1 попробовал создать файл, не получилось, причём проблема создать даже aux. В интернетах пишут, что это наследие ещё от DOS. И не просто зарезервированные имена, а зарезервированные начала имён. Выглядит это конечно крайне глупо. Как всегда, говноделы из майкрософт создали проблемы, а виноваты все остальные.

В данном случае говноделом, создавшим проблемы, был Gary Kildall, автор CP/M, который при общем копировании подходов из RSX-11, RT-11 и близких систем, сделал две диверсии:

1. Вместо отдельного пространства имён устройств сделал детект в пространстве имён.
В результате, например, там, где писали copy foo.txt prn:, которое раскрывалось в copy foo.txt prn:foo.txt (после чего драйвер мог по имени и суффиксу определить режим печати, нарисовать заголовок и так далее), он сделал, что писали copy foo.txt prn, где ключевая информация терялась.

2. Урезал имена дисков (где могло быть, например, dk0:, dk1: — по пути к драйверу, sys: — загрузочный, ещё и алиасы можно было создавать) до одной буквы, создав кучу проблем с бардаком в тесном пространстве.

(Это всё слабо оправдывается ресурсами компов на 8080: RT-11 успешно работала на 16-битном PDP-11 в 56KB памяти со всеми такими возможностями. Просто ему так захотелось.)

Microsoft слямзила этот подход 1:1 в MS-DOS (и, по некоторым конспирологиям, помогла Килдаллу отправиться в страну вечной охоты, чтобы не жаловался на передирку 1:1 его разработок), исправлять не стали (они тут уже начали заботиться о совместимости, в отличие от).

Вот то, что MS при получении огромных ресурсов не выправили это обратно — вот в этом уже их вина.