никто не понимает проблему папок, каждый раз мне тыкают гитигнор и гиткип )
Потому что то изначально git работает в unix-системах, где "все есть файл", а пустая директория это ничего.
Далее очень плохо написано, что не понятно из-за чего возникает конфликт: если файлы были просто перенесены, git видит это как rename, другое дело что может быть проблема когда переносятся бинарные файлы (.so, .dll, etc.), то нужно в gitattributes явно указывать особенности обработки их изменений, чтобы git понял, что это был именно rename, а не deleted+created.
По прежнему перечисленные проблемы выглядят как неправильный выбор инструмента + неумение им пользоваться
гит не удобен для геймдева, где много бинарных данных
ЕМНИП, в геймдеве доминирует helix, так что это плохой выбор инструмента, а не плохой инструмент
гит не поддерживает папки, только файлы, юнити генерит для папок меты, и начинается то стирание их то создание на разных машинах
.gitkeep, .gitignore, итд
в гите левый слеш и правый, это разные вещи, файлы лежат технически в разных папках, хотя на целевой машине это один и тот же файл
проблема разных ОС у участников, ФС windows и macos регистронезависимы поэтому такое всплывает
в гите нет режима среза, приходится постоянно делать транкейт, потому что приходится выкачивать все изменения файлов, но наверно эту проблему решает deep параметр
deep indeed
Так и получается, что использовать git в геймдеве выглядит как попытка закрутить шуруп молотком.
Весь 2025й провел без работы после сильного выгорания и депрессии и не иронично думал над подобным - уйти в подобную рабочую профессию. На момент этого комментария, неделю как вышел на новую работу, но подобные мысли только усилились.
Конфигурация - это не код. Код проходит code review, линтеры, тесты, CI. Конфигурация - чаще всего нет.
Сразу не согласен. Точнее так - в реальной жизни оно именно так, к конфигурации редко относятся как к коду и это плохо. Делать хотя бы минимальный линтинг и тестирование, вводить практики code review должно быть такой же нормой как для кода приложений.
Ну пиксель кажется единственным нормальным вариантом если нужен +/- актуальный android, потому что если верить этому, не наглухо закрытых загрузчиков не осталось
конкретно в айфоне из-за его ограничений например syncthing не умеет фотки сливать в фоне на комп
Кажется что дело не в ограничениях ios, потому что resilio существует и работает, а в том что не написали нормальное приложение именно для syncthing
А шаги влево-вправо - они про что? и какие варианты есть с андроидом сейчас? Просто как раз столкнулся с тем, что пора бы уже думать менять телефон (сейчас iphone 11) и вот что-то вообще ничего не устраивает, ни у яблока, ни у не-яблока
Ну я вот пытался внедрить Ansible на протяжении многих лет. Не идёт. Слишком сложно для таких масштабов, как у меня.
В статье говорится про 1-5 тачек - если не это идеальная возможность поработать с ansible, то что? Проще разве что из tmux панелей подключаться ко всем тачкам разом и через pane-synchronize один shell'ник, запускать
Делаю копию проекта и работаю уже с ней. В предыдущей итерации описываю в doc-файле, что там реализовано, какие возникли проблемы и что собираюсь делать дальше <...> Если возникает «затык», что бывает регулярно, просто возвращаюсь к предыдущей, рабочей версии проекта и начинаю все заново.
Ну то есть я правильно понимаю, что вместо нормального контроля версий, все держится на собственной памяти и директориях вида "Проект", "Проект (1)", "Проект (2)" и т.д.?
устанавливает больше инструментов — очевидный минус, я не хочу, чтобы мне кто-то зачем-то устанавливал больше каких-то там еще инструментов
Максимально странный поинт, типа - что плохого, что в регистри mise больше тулинга, который можно установить?
поддержка переменных окружения — три раза нет, ну может быть, иногда удобно, хотя для этого тоже есть миллион инструментов;
Ну вот встречный вопрос - а зачем мне мучаться с "миллионом инструментов"?
неангажированный вывод для тех кто сюда забредет: если у вас уже asdf, вам вряд ли понравится, если нет — лучше, наверное, начинать прямо с mise
Пересел с asdf спустя год использования на mise еще во времена, когда mise был rtx - вообще ни о чем не жалею: была постоянная боль с asdf+make+direnv+доморощенные shell-хуки - все заменилось одним, которые сразу работает нормально.
Ни разу в жизни не видел того, кого бы устраивал makefile, везде где его встречал это был write-once костыль, который и открывать то было стремно, не говоря уже о добавлении чего-то нового.
Вообще обычно для подобных случаев использутеся связка из:
require-dev блока в композере, npm и т.п., чтобы ставить зависимости нужные для разработки только если они нужны
Речь о разных зависимостях - mise не заменяет условный composer.json или package.json и не управляет зависимостями библиотек в проекте. Но и composer при наличии в require "php": ">=7.4" нужную версию php не установит, в отличии от mise. Более того - имея несколько проектов с разными версиями того же php, mise автоматически подставляет в PATH нужную, снимая всю головную боль с update-alternatives и прочими приседаниями с тем "а какая версия php/node/python/ruby/etc. у меня сейчас". (Хотя в наше время и без контейнера это уже анахронизм)
.env все же более универсальный механизм и позволяет не хранить все секреты в одном месте
И он тоже поддерживается mise. Если пользовались direnv - это и его замена в том числе.
Что касается разъезжающихся версий у разрабов - если человек по каким-то причинам не обновляет инструментарий, ему утилиты не помогут.
Это +\- работает если разработчик один и проектов или немного или они все однотипные. В крупных проектах ситуация, когда версия языка отстала от актуальной, хорошо если не на мажорную (как часто с php), а хотя бы на 2-3 минорных, встречается в примерно 90% случаях, а сам процесс обновления - тот еще техдолг.
Но может ваша утилита и взлетит
Давненько уже взлетела, как и сама концепция - достаточно глянуть и что альтернативы появились - aqua, vfox, и что "родоначальник" asdf из набора bash-скриптов переписался полностью на go
питоновский uv вон набирает популярность, хотя его смысл вообще мне не понятен.
pyenv, pip, pipenv, virtualenv, poetry - ни о чем не говорят? Если да - вы скорее всего не работали над крупными проектами и/или в крупных компаниях
Сам люблю mise всей душой, еще со времени когда он назывался rtx, и делал пару контрибьютов в его регистри, но статья слабо продающая, что видно в комментах. Не хватает прям практического примера, что мол "вот у нас проект на такой-то python, в нем и makefile, и .python-version, и .env, и requirements.txt, а вот так mise во все это интегрируется практически нативно, но еще больше фичей можно получить если взять mise.toml".
Потому что то изначально git работает в unix-системах, где "все есть файл", а пустая директория это ничего.
Далее очень плохо написано, что не понятно из-за чего возникает конфликт: если файлы были просто перенесены, git видит это как rename, другое дело что может быть проблема когда переносятся бинарные файлы (.so, .dll, etc.), то нужно в gitattributes явно указывать особенности обработки их изменений, чтобы git понял, что это был именно rename, а не deleted+created.
По прежнему перечисленные проблемы выглядят как неправильный выбор инструмента + неумение им пользоваться
Что под этим подразумевается?, если я правильно понял, то надо просто worktree использовать чтобы один поток не меня то, что делает другой
ЕМНИП, в геймдеве доминирует helix, так что это плохой выбор инструмента, а не плохой инструмент
.gitkeep, .gitignore, итд
проблема разных ОС у участников, ФС windows и macos регистронезависимы поэтому такое всплывает
deep indeed
Так и получается, что использовать git в геймдеве выглядит как попытка закрутить шуруп молотком.
Весь 2025й провел без работы после сильного выгорания и депрессии и не иронично думал над подобным - уйти в подобную рабочую профессию. На момент этого комментария, неделю как вышел на новую работу, но подобные мысли только усилились.
Сразу не согласен. Точнее так - в реальной жизни оно именно так, к конфигурации редко относятся как к коду и это плохо. Делать хотя бы минимальный линтинг и тестирование, вводить практики code review должно быть такой же нормой как для кода приложений.
Ну пиксель кажется единственным нормальным вариантом если нужен +/- актуальный android, потому что если верить этому, не наглухо закрытых загрузчиков не осталось
Кажется что дело не в ограничениях ios, потому что resilio существует и работает, а в том что не написали нормальное приложение именно для syncthing
А шаги влево-вправо - они про что? и какие варианты есть с андроидом сейчас? Просто как раз столкнулся с тем, что пора бы уже думать менять телефон (сейчас iphone 11) и вот что-то вообще ничего не устраивает, ни у яблока, ни у не-яблока
Пользуюсь v2raytun - он пропал, конкретный список вроде бы еще не публиковался
Так можно сказать про абсолютно (ну ладно, 95%, где 5% - с отсевом по строго физиологическим причинам) любую работу
В статье говорится про 1-5 тачек - если не это идеальная возможность поработать с ansible, то что? Проще разве что из tmux панелей подключаться ко всем тачкам разом и через pane-synchronize один shell'ник, запускать
А зарубежные банки в белых списках
Ну то есть я правильно понимаю, что вместо нормального контроля версий, все держится на собственной памяти и директориях вида "Проект", "Проект (1)", "Проект (2)" и т.д.?
А что тогда используете для версионирования и/или обеспечения переносимости своих пет-проектов если не гит?
ИМХО, вообще лучше snap не пользоваться когда есть flatpak
https://asahilinux.org/
Оно не только открыто, но и воспроизводится до сих пор
Максимально странный поинт, типа - что плохого, что в регистри mise больше тулинга, который можно установить?
Ну вот встречный вопрос - а зачем мне мучаться с "миллионом инструментов"?
Пересел с asdf спустя год использования на mise еще во времена, когда mise был rtx - вообще ни о чем не жалею: была постоянная боль с asdf+make+direnv+доморощенные shell-хуки - все заменилось одним, которые сразу работает нормально.
Ни разу в жизни не видел того, кого бы устраивал makefile, везде где его встречал это был write-once костыль, который и открывать то было стремно, не говоря уже о добавлении чего-то нового.
Речь о разных зависимостях - mise не заменяет условный composer.json или package.json и не управляет зависимостями библиотек в проекте. Но и composer при наличии в require
"php": ">=7.4"нужную версию php не установит, в отличии от mise. Более того - имея несколько проектов с разными версиями того же php, mise автоматически подставляет в PATH нужную, снимая всю головную боль с update-alternatives и прочими приседаниями с тем "а какая версия php/node/python/ruby/etc. у меня сейчас". (Хотя в наше время и без контейнера это уже анахронизм)И он тоже поддерживается mise. Если пользовались direnv - это и его замена в том числе.
Это +\- работает если разработчик один и проектов или немного или они все однотипные. В крупных проектах ситуация, когда версия языка отстала от актуальной, хорошо если не на мажорную (как часто с php), а хотя бы на 2-3 минорных, встречается в примерно 90% случаях, а сам процесс обновления - тот еще техдолг.
Давненько уже взлетела, как и сама концепция - достаточно глянуть и что альтернативы появились - aqua, vfox, и что "родоначальник" asdf из набора bash-скриптов переписался полностью на go
pyenv, pip, pipenv, virtualenv, poetry - ни о чем не говорят? Если да - вы скорее всего не работали над крупными проектами и/или в крупных компаниях
Сам люблю mise всей душой, еще со времени когда он назывался rtx, и делал пару контрибьютов в его регистри, но статья слабо продающая, что видно в комментах. Не хватает прям практического примера, что мол "вот у нас проект на такой-то python, в нем и makefile, и .python-version, и .env, и requirements.txt, а вот так mise во все это интегрируется практически нативно, но еще больше фичей можно получить если взять mise.toml".