Comments 35
Не надо так делать. dd - это программа, go - это компилятор, ll - часто ls -l, reset - это команда шелла. Неужели сложно написать git в начале?
Примерно так
git() {
if [[ $@ == "f" ]]; then
command git fetch --tags
elif [[ $@ == "s" ]]; then
command git status
else
command git "$@"
fi
}Bash documentation:
For almost every purpose, shell functions are preferred over aliases.
Зачем вообще использовать Баш вместо Гит алиасов?
возможно потому что bashrc/zshrc/etc с собой таскать проще чем bashrc+gitconf+ещёпачкувсего
Про какую пачку речь? Все алиасы хранятся в одном .gitconfig файле.
но кроме гита используется ещё 100500 софтин и утилит на постоянной основе
можно сделать git init в домашней директории и синхронизировать все свои настройки на всех компьютерах
увы но нет
прийдётся писать огромный .gitignore файлик в котором заигнорено будет больше чем попадёт в репу потому что есть некотоорые софтины к примеру гуглохром запуск двух экземпляров которых одновременно на разных тачках приведут к проблемам, а есть софтины дотфайлы которых нет смысла таскать с собой везде (те кто пишет на ноде, го или расте сейчас дружно закивали головой). к тому же git не автоматизирует синхронизацию а лишь уменьшает кол-во действий для неё
я использую resilio (да мне просто лень переехать на synthing) синхроню отдельную директорию из которой часть конфигов отправляю в хомяк симлинками а часть через mount bind, и это тоже костылизм потому что некоторые софтины не могут работать с конфигом через симлинк (примеры rclone и cherrytree). приходится постоянно руками (ну не совсем руками, через ansible но всё равно не автоматически) поддерживать все нужные связи между папкой синхрона и хомяком на разных тачках (у меня это два pc и два ноута).
давно есть идея создать для этого инструмент который бы заранее знал каким конфигам можно симлинк а каким маунтбинд и при появлении определённого конфига на одной тачке делал всё необходимое на второй. но пока это идея в зачаточной стадии
Есть настройка ignore untracked: пока явно не начнёшь трекать какой-нибудь конфиг, git status будет пуст.
еще есть вариант с тем чтобы такой репозиторий держать в ~/.dotfiles и оттуда сделать линки на всякие .vimrc и прочее (https://github.com/platinumthinker/dotfiles/blob/master/bootstrap.sh)
Большая часть алиасов выполнена по схеме alias n='git n'
Идея настолько очевидная, что ценность статьи не очень понятна :)
Поделиться существующей практикой и идеями. Я уже достаточно давно использую алиасы, они оказались намного удобнее, чем вводить команды целиком, причём именно в таком виде, легко запоминаются, нет никакой путаницы, действия доводятся до автоматизма. Собственно, основной моей деятельностью в консоли является работа с git.
Ну и в интернете список алиасов всегда под рукой. :)
dd и reset - существующие утилиты, к git никак не относятся.
dd используется или через sudo, или от имени суперпользователя. В обоих случаях алиасы работать перестают, поскольку прописаны у непривилегированного пользователя. На моей практике у меня не возникало проблем с существующими командами.
Если алиасы совпадают с командами, которые в норме не используются, то проблем нет. Именно поэтому я лишь про команду go упомянул.
Отразил данную информацию в статье.
dd используется или через sudo, или от имени суперпользователя
dd используется по разному. Git, кстати, тоже. А делать алиасы, совпадающие с существующими программами, это вредительство.
Чем же это может вредить? С таким же успехом навредить может кастомизация горячих клавиш. Мне не нравится F2 для переименовывания файлов, я её на другое действие переназначаю. Алиасы предназначены для катомизации терминала под себя, как будет удобно именно отдельному человеку. Из людей, с кем я работал, один взял мой вариант, а другой сделал себе свои, совсем другие, алиасы.
Что касается пересечений с названиями команд, то писать /bin/dd будет даже более хорошей практикой в скриптах, поскольку исключает пересечение с алиасами. Если часто требуется выполнять эту команду из консоли, то можно не прописывать автоматическое подключение алиасов в bashrc, а инициализировать их раз в день в рабочей консоли отдельной командой. Либо же подобрать другое название, например, dc (diff, color).
И если уж называете вредительсвом, то давайте расшифровку того, что имеете в виду, какие именно случаи, и какой вред в этих случаях алиасы могут нанести.
В скриптах алиасы не работают. Вы можете в скриптах продолжать писать dd.
писать /bin/dd будет даже более хорошей практикой в скриптах, поскольку исключает пересечение с алиасами
Такой скрипт не будет портабельным, потому абсолютный путь может отличаться на разных системах. Чтобы игнорировать алиас или шел функцию достаточно поместить название команды в кавычки либо запускать через command.
Чем же это может вредить?
Ну, можно представить кулхацкера, который на своей любимой системе виндовз сделал глубокий апгрейд: поменял картинки и подписи на всех ярлыках, потому что ему удобно, когда вместо иконки 'мой компьютер' - мусорная корзина. Вредит он только себе - с такими нестандартными привычками за любым другим компьютером ему будет неудобно.
почему бы не использовать .gitconfig для алиасов и не плодить конфликты в bash командах? или это очередная статья из разряда придумал не знаю для чего, но могу вот так...
И сколько секунд экономит нам pull вместо git pull? Сейчас угадаю - 0. При скорости печати 200-300зн/м вслепую и редкости операции.
Там и так все сокращено, куда еще? Вы еще команды линуха/макОС уже до букв аббревиатур сокращенные посокращайте
В громоздких запросах бд - псевдонимы необходимость. А в гите то на кой?
Это мое мнение, можно пинать.
Если не предвзято взглянуть на первую часть статьи, то, в принципе, имеем неплохую подсказку по командам git для начинающего пользователя.
А зачем вам алиас на git pull? Я ума не приложу зачем эта команда может понадобиться. Я в 100% случаев зову git pull --rebase.
А что не так с git pull? Ну вот лежит у меня master, хочу я с сервера свежие комитты подтянуть в него, так и использую git pull. Или я чего-то не понимаю?
Проблема в том, что эти свежие комитты будут вмержены в вашу текущую ветку, причём ваша ветка будет считаться основной. Это не проблема если вы работаете в отдельной ветке, которую потом будете мержить обратно, но если результат git pull запушить — большинство инструментов построения списков изменений поломаются.
Ну а если вы и вовсе PR готовите, то там комиты слияния выглядят попросту некрасиво.
А теперь ищем в поиске гитхаба 'dotfiles', открываем любой репозиторий, заходим в .bashrc / .zshrc и видим, что вешать алиасы на все частые команды, не только git - повсеместная практика. Заодно понимаем, что алиасы 'll', 'gs' и тем более 'go' - очень и очень плохие.
Зачем это нужно, если есть powerlevel10k?)
tudoy/sudoy/getoverhere/nunafig
Вообще я иногда испльзую аллиасы только при хронических ошибках и сильном постоянстве (ls/sl, чтоб паровозик не вызывал, ip ч тоб всегда был с -c и т.д.).
Как бы не звучало, но имхо по аллиасам мана достаточно.
Алиасы в bash для быстрого набора команд Git