Legit: sexy git CLI

[@x8tty]

>на Python
>не только на Mac
и это действительно неожиданно

[@tampere]

:)
Ну, скажем, если бы он был на Руби, как часто делают фанаты гитхаба, было бы уже не так удобно, хотя и тоже кроссплатформенно.

[@cypok]

А в чем разница? Что-то тот, что тот есть под основные платформы и не составляет труда их установить.

[@tampere]

В руби неудобные зависимости от версий gem'ов. То есть, если разворачивается сложное приложение, например, gitorious, то может получиться, что требуется установить какой-нибудь старый пакет. Различия между версиями, опять же, менее очевидны. Т.е., если для питона зависимость может быть от второй циферки в версии, то в руби уже от третьей.
Руби нравится мне как язык, но как экосистема для разработки он пока не очень мне подходит. Хотя отдельные штуки на нём мне очень нравятся, тот же Jekyll, например.

[@sn00p]

Да, gitorious мы долго побеждали.
Пришлось перебирать различные варианты версий ruby и используемых gemов. Вообще на поток ruby поставить довольно тяжело, настройка сложного приложения может превратиться в долгий увлекательный процесс. В репе той же убунты все пакеты и джемы морально устаревшие, приходится много делать и ставить вручную.

[@Kane]

По-моему, вы описываете проблемы отдельных приложений, а не руби в целом.
Как в ruby gems, так и в bundler вы можете указать любые зависимости.

[@tampere]

Это я понимаю. А как правильно установить два гема, например, версии 0.9.9 и 1.0.1, чтобы выбирался правильный? Что-то такое было в gitorious с geoip.

[@Kane]

А как вы себе представляете одновременное использование двух джемов? Если у вас два одинаковых джема, значит у вас одновременно два одинаковых класса. Конечно, так быть не может. Тут либо нужно обернуть во что-то один из классов, либо попытаться решить эту проблему ещё как-то, например попросить авторов одного из пакетов обновить зависимости.

[@Sannis]

А вот npm для Node.js вполне спокойно умеет установливать сразу нескольок версий пакета и подключать нужные в зависимости от зависимости текущенго приложения. Да что уж тут говорить, разделённый библиотеки в *nix могут быть установлдены сразу нескольких версий.

[@Kane]

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

[@Sannis]

Почему нет? если разные зависимости приложения могут в свою очередь зависеть от разных версий какой-то одной библиотеки, то что должно мешать разработчику использовать две версии одной бибилотеки напрямую в приложении? Собственно, npm в Node.js может и это.

[@Kane]

Приведи, пожалуйста, пример кода.
В руби это нельзя сделать потому что две разные версии одной библиотеки будут иметь одно и тоже имя класса.

[@Sannis]

Выглядит это примерно так:

// Get some API module in 3.1 version
var api3 = require('someapi@3.1');

// Work with 3.1 API
api3.get(params, callback);

// Get some API module in 2.3.8 version
var api2 = require('someapi@2.3.8');

// Work with 2.3.8 API
api3.get(params, callback);

В целом это заслуга JavaScript, что такое можно провернуть не упираясь в ограничения вроде единственности имени класса. В данном случае как такового класса нет.

[@Kane]

Это-то понятно. Вам не показалось, что само по себе желание использовать две версии одной библиотеки разом странным?

Речь идёт о уже готовых проектах которые нужно использовать совместно и которые требуют двух разных версий одной библиотеки.

[@Sannis]

Вот как раз в этом случае это кажется мне совсем не странным. Просто пример кода взял самый простой :)

[@merc]

bundler вам на что?

[@Kane]

Если в одно приложении нужны две разные версии одной библиотеки, то bundler не поможет.

[@merc]

тогда уже ничего не поможет :)

[@Kane]

В том то и дело. И я сомневаюсь что в python можно иметь библиотеку одновременно двух разных версий. Не понятно, почему автор выставляет это как недостаток руби.

[@svetlov]

В Питоне есть virtualenv предназначенный именно для работы с разными версиями на одной машине

[@Kane]

На одной машине или одновременно в одном приложении?

[@svetlov]

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

[@tampere]

Не в одно приложение, а в разные. Иногда не видятся гемы, хотя они есть, или не устанавливаются.

[@painEffect]

тут поможет rmv и его гемсеты

[@tampere]

Спасибо за подсказку, понял, что делать дальше )

[@painEffect]

не за что. я еще и опечаться в 3-х буквах умудрился. речь об rvm, конечно же

[@victorI]

тут как раз bundler решает, см Gemfile.lock

[@painEffect]

если проблема со сторонним приложением, то bundler решает хуже чем rvm

[@vovaua]

bundler вам в помощь

[@aspect]

Прямо ирония судьбы. Почему бы тогда не дойти до логического завершения и не использовать hg

[@datacompboy]

Простите, а чем это лучше банальных .cmd/.sh выполняющиъ эти функции?!
таскать червя ради пары команд по очереди — бредятина.

[@slayerhabr]

я бы сказал даже alias/function

[@datacompboy]

alias'ом не всегда можно реализовать логику

[@tampere]

В общем, так оно и есть, только скрипты на питоне, а не на шелле.

[@datacompboy]

ну то есть вместо готового скриптователя возьмём громадный который надо доставлять.

[@painEffect]

как на счет поделиться с нами своими .cmd/.sh, выполняющими эти функции?

[@datacompboy]

Я не знаю что делают вышеуказанные, из описаний выходит вот что они делают (пишу так, чтоб можно было в bash функцию положить):
git branch -a
— получить список всех бранчей.
BRANCH=${1:?«Supply branch name»} && git stash && git checkout $BRANCH && git stash pop
— переключиться на ветку
git checkout -b newbranch
— переключиться на новый бранч с содержимым текущего
git checkout into-branch && git merge branch && git branch -d branch
— слить первый бранч во второй и удалить первый. Можно сливать только локальный бранч.
git stash && CUR=$(git rev-parse HEAD) && git checkout branchname && git push origin branchname && git checkout $CUR && git stash pop
— Добавить удалённый бранч из соответствующего локального.
git push origin :branch
— Убрать удалённый бранч.

Я не совсем понимаю что делает sync, но явно что-то не сложнее
git stash && CUR=$(git rev-parse HEAD) && git checkout master && git pull && git checkout $CUR && git rebase master && git stash pop

[@painEffect]

Спасибо!

[@TiGR]

Не хватает только обработки ошибок.

[@datacompboy]

"&&" прервет выполнение в случае ошибки на каком-либо из шагов.
При желании, можно добавить || случаи для «восстановление из ошибок».

[@TiGR]

Да, я в курсе про &&, имелось в виду в первую очередь именно восстановление из ошибок.

[@datacompboy]

У меня небогатый опыт работы с git, я встречал только ошибки двух типов — 1й «кто-то сделал фигню» и 2й «ты сам сделал фигню». В обоих случаях, проблема решалась через git reset --hard <коммит>.
Поэтому я не знаю, как надо восстанавливаться из ошибок :(

[@tampere]

Здесь могу добавить, что аналогичные алиасы можно задавать в ~/.gitconfig:
[alias]
st = status
pr = pull --rebase
co = checkout

Соответственно, вызывать нужно git [st|co|pr|...].

[@vovaua]

это не одно и тоже в ~/.gitconfig сокращения для git комманд,
в ~/.profile или в ~/.bashrc – сокращения для вызовов git с параметрами, т.е. так вы можете весь Legit в aliasы унести.

[@murr]

Не совсем сокращения, можно и команды писать, например, вот строчка из моего .gitconfig

[alias]
...
rmd = rm $(git ls-files --deleted)

Хранить такие команды в конфиге гита удобнее, если разработка идет на нескольких машинах с зоопарком шелов (bash, zsh etc), просто синхронизировав ~/.gitconfig

Можно извращаться вызывать и чисто системные утилиты:

qq = !echo "HELLO"

или для пуристов:
qq = !sh -c 'echo "HELLO"'

Понятно, что системные алиасы, не имеющее отношения к гиту хранить в гитконфиге странно, но мало ли.

По алиасам есть хорошая страничка на вики: git.wiki.kernel.org/index.php/Aliases

[@vovaua]

а еще есть волшебный git flow