Поддерживаю. ИМХО, если уж и ставить подобный бандл, то лучше powerlevel10k (от автора приведенного бенчмарка, а он шарит) или starship (скомпиленный rust, кажется, будет быстрее, чем sh)
Да, вкусовщина по большей части. Из плюсов могу только выделить нативную работу со структурами, типа json/yaml/csv/etc., ЕМНИП в powershell оно так же не нативно, как в bash (ну то есть через jq/yq/etc.)
Для кого-то с диагнозом "непринятие всего от microsoft" может быть плюсом кроссплатформенность.
да на самом деле тысячи их - писать плагины довольно просто, поэтому очень много однотипных или форков, почти не отличающихся от оригинала (да, у меня тоже форк)
После 5 лет на zsh после 4х лет на bash, могу уверенно ответить - ничего, ничего не даст.
Да, можно сделать "красиво" с помощью костылей типа oh-my-zsh (хуже), powerlevel10k (лучше) или своими руками, но с большего - мало что поменяется, т.к. большая часть плагинов это все же bash диалект (например в большинстве моих плагинов шебанги #!/usr/bin/bash, ну а если хочется "все самое новое", то тогда уже ИМХО лучше на nushell переехать
Плагины git и composer, судя по тому что написано в статье - экономия на спичках вида "спасибо > спс"
Thinkpad при этом вещь действительно крутая. Чего стоит одно то, что на них можно чашку воды на клаву вылить, и она просто уйдет через специальные каналы.
Yaml-файл в git-репозитории каждого проекта, в который по ходу дела докидывается инфа типа ip-адреса, где у нас зарегана почта, где управляем DNS-записями:
На 3х моих последних работах так же всё пытались переизобрести service discovery: на одной - решили что Consul нам мало дает (на самом деле мы еще не умели его готовить) и придумали "паспорт сервиса", но реализовать не успели; на другой придумали настолько умную спецификацию паспорта, что реализовать не смогли; на третьей - взяли https://backstage.io/ да "забороли проблему".
Да, но не "заметно", кажется что не более 2 часов. А вообще хотел был попробовать эксперимент - с месяц пожить без естественного света вообще и понять какие мои реальные сутки, потому что "сова та еще"
Предлагаю в качестве мысленного эксперимента представить статьи на хабре и комментарии к ним в виде голосовых сообщений. Представить как будет реализован поиск, цитирование, ссылки, вложения и т.д.
Вот примерно так же вижу идею с хранением исходного кода в чем-то отличном от текстового файла.
Жаль homebrew (ну, точнее пакетный менеджер в целом) никак не встроят в саму macos, когда как windows успешно (относительно) совмещает магазин приложений и winget
Не знаю как остальные, но почему поставил минус я:
git rebase лучше стараться избегать, практически всегда можно обойтись без переписывания истории
rebase не про переписывание истории, это только одна из возможностей
Просмотр истории/веток/диффов и прочего все-таки сильно удобнее через UI, вроде Git Graph плагина к VS Code
это вкусовщина которая мне "не отзывается", единственное что мне удобнее делать в UI это разрешение конфликтов
git checkout - только на больших репозиториях с множеством веток когда вдруг надо перкключится на какую-то старую ветку до которой долго листать UI, обычно между ветками нагляднее через UI переключаться
снова вкусовщина - имхо, автодополнение и fzf в консоли удобнее, чем глазами искать имя ветки, + вместо checkout рекомендуется switch
в статье не хватает git blame - оно нужно чтоб найти кто изменения сделал
с этим согласен; вообще многого в статье не хватает, например флага --patch для add/restore, но для заголовка "Основные" - пойдет
Поддерживаю. ИМХО, если уж и ставить подобный бандл, то лучше powerlevel10k (от автора приведенного бенчмарка, а он шарит) или starship (скомпиленный rust, кажется, будет быстрее, чем sh)
Да, вкусовщина по большей части. Из плюсов могу только выделить нативную работу со структурами, типа json/yaml/csv/etc., ЕМНИП в powershell оно так же не нативно, как в bash (ну то есть через jq/yq/etc.)
Для кого-то с диагнозом "непринятие всего от microsoft" может быть плюсом кроссплатформенность.
да на самом деле тысячи их - писать плагины довольно просто, поэтому очень много однотипных или форков, почти не отличающихся от оригинала (да, у меня тоже форк)
После 5 лет на zsh после 4х лет на bash, могу уверенно ответить - ничего, ничего не даст.
Да, можно сделать "красиво" с помощью костылей типа oh-my-zsh (хуже), powerlevel10k (лучше) или своими руками, но с большего - мало что поменяется, т.к. большая часть плагинов это все же bash диалект (например в большинстве моих плагинов шебанги
#!/usr/bin/bash, ну а если хочется "все самое новое", то тогда уже ИМХО лучше на nushell переехатьПлагины git и composer, судя по тому что написано в статье - экономия на спичках вида "спасибо > спс"
Для себя имею такой набор плагинов:
https://github.com/tony-sol/git-aware-prompt - состояние репозитория для подстановки в PROMPT/RPROMPT
https://github.com/marlonrichert/zsh-autocomplete - автокомплит
https://github.com/zsh-users/zsh-autosuggestions - предложение на основе истории/окружения
https://github.com/zsh-users/zsh-completions - набор скриптов комплита от сообщества
https://github.com/qoomon/zsh-lazyload - ленивая загрузка (использую для автодополнения команд, например
lazyload kubectl -- 'source <(kubectl completion zsh)', благодаря чему уменьшается лаг (см. https://github.com/romkatv/zsh-bench)https://github.com/tony-sol/zsh-ssh - интеграция fzf в автодополнение ssh
Тогда уже nushell вместо zsh на *nix/powershell на windows
да давно уже
тут скорее вопрос - почему choco вместо нативного winget, у которого к тому же есть DSC
Не на всех, на X1 да, на T14 - нет
На 3х моих последних работах так же всё пытались переизобрести service discovery: на одной - решили что Consul нам мало дает (на самом деле мы еще не умели его готовить) и придумали "паспорт сервиса", но реализовать не успели; на другой придумали настолько умную спецификацию паспорта, что реализовать не смогли; на третьей - взяли https://backstage.io/ да "забороли проблему".
За эти 3 подхода я
очень усталпонял, что:универсального решения не будет (К.О.)
https://xkcd.com/927/ будет актуально всегда
всегда нужно встраиваться в имеющуюся инфраструктуру
ИМХО, для всего что связано с веб, нет смысла делать что-то вне парадигмы kubernetes, а там подобного рода тулинга достаточно
Да, в середине 24го сгорел, кое-как жил и в итоге с марта 25го не работаю и нет никаких сил вернуться
Да, но не "заметно", кажется что не более 2 часов. А вообще хотел был попробовать эксперимент - с месяц пожить без естественного света вообще и понять какие мои реальные сутки, потому что "сова та еще"
Предлагаю в качестве мысленного эксперимента представить статьи на хабре и комментарии к ним в виде голосовых сообщений. Представить как будет реализован поиск, цитирование, ссылки, вложения и т.д.
Вот примерно так же вижу идею с хранением исходного кода в чем-то отличном от текстового файла.
Это если squash включен, + есть rerere
перед add всегда делаю diff ровно с той же целью, + примерно в половине случаев add с флагом --patch
Звучит неправдеподобно - есть пример?
Можете закидать меня помидорами, но ИМХО usb-a реально пора выкидывать, нет у него преимуществ перед type-c
Жаль homebrew (ну, точнее пакетный менеджер в целом) никак не встроят в саму macos, когда как windows успешно (относительно) совмещает магазин приложений и winget
Это хорошо, что не пригодился)
Мне reflog помог восстановиться после неудачного push --force
Не знаю как остальные, но почему поставил минус я:
rebase не про переписывание истории, это только одна из возможностей
это вкусовщина которая мне "не отзывается", единственное что мне удобнее делать в UI это разрешение конфликтов
снова вкусовщина - имхо, автодополнение и fzf в консоли удобнее, чем глазами искать имя ветки, + вместо checkout рекомендуется switch
с этим согласен; вообще многого в статье не хватает, например флага --patch для add/restore, но для заголовка "Основные" - пойдет
Mission control конечно хорош, но имхо лучше один раз заморочиться с https://github.com/nikitabobko/AeroSpace
ах, style xp, ностальхия
helix печалит своим комьюнити (точнее его отсутствием), кажется из-за этого разработчики и не торопятся добавлять поддержку плагинов