Comments 35
Наконец-то можно легко делать разные приватные ключи для разных репозиториев:
GIT_SSH_COMMAND='ssh -i git_id' git clone host:repo.git
ИМХО, «старый» способ с ~/.ssh/config куда проще и удобнее.
Для end user — да. Для автоматизации — не очень. Если у нас есть скрипт который хочет сходить на несколько десятков репозиториев, то для этого скрипта менять user-wide конфигурацию всего ssh как-то не по феншую. Дописал это в новости, спасибо!
Как .ssh/config поможет с двумя разными ключами на гитхабе/битбакете?
Элементарно. Хоть 2, хоть 100500.
Вам пример нужен?
Вам пример нужен?
Нужен.
Проект первый: git@bitbucket.org:foo/foo, используется key1
Проект второй: git@bitbucket.org:bar/bar, используется key2
Как такое задать через .ssh/config?
Проект первый: git@bitbucket.org:foo/foo, используется key1
Проект второй: git@bitbucket.org:bar/bar, используется key2
Как такое задать через .ssh/config?
С алиасами-то понятное дело, но это придется bitbicket.org в remote url поменять на алиас. Это неудобно при параллельном использовании написанных на Java IDE (JetBrains IDEA и подобных), которые не умеют читать .ssh/config. Можно прописать в /etc/hosts, конечно, но это совсем ужасный хак, да и IP-адрес Битбакета может измениться. Вариант с GIT_SSH_COMMAND удобнее и легко заворачивается в алиас.
Это неудобно при параллельном использовании написанных на Java IDE (JetBrains IDEA и подобных), которые не умеют читать .ssh/config.WAT?
IntelliJ IDEA supports a standard method of using multiple ssh keys, by means of creating .ssh/config file.
Вариант с GIT_SSH_COMMAND удобнее и легко заворачивается в алиас.Действительно: что может быть удобнее заворачивания алиаса в алиас.
На сколько я помню в .ssh/config можно задать алиасы для конфигов.
Не совсем так, но в целом верно: алиасы задаются не конфигам, а хостам.
~/.ssh/config:
после этого достаточно либо сделать:
либо поменять remote.url в .git/config для уже склонированных репо.
# GitHub
Host project1.github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile /path/to/key1
Host project2.github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile /path/to/key2
после этого достаточно либо сделать:
git clone git@project1.github.com:repo1
git clone git@project2.github.com:repo2
либо поменять remote.url в .git/config для уже склонированных репо.
Так же можно использовать
User
чтобы для одного Host
подхватывались разные ключи для разных юзеров.Host github.com
User foo
PreferredAuthentications publickey
IdentityFile /path/to/key-foo
Host github.com
User bar
PreferredAuthentications publickey
IdentityFile /path/to/key-bar
Жаль что Windows версия сильно отстает от своего апстрима.
Ни то что 2.3, там даже 2.0 не пахнет (
Ни то что 2.3, там даже 2.0 не пахнет (
Latest source Release
2.3.0
Release Notes (2015-02-05)
Downloads for Windows
Особенно обидно такое видеть на главной странице GIT.
С радостью жмакаеш «скачать» и получаешь 1.9.5 :(
2.3.0
Release Notes (2015-02-05)
Downloads for Windows
Особенно обидно такое видеть на главной странице GIT.
С радостью жмакаеш «скачать» и получаешь 1.9.5 :(
Они переделывает там всю внутреннею структуру насколько понял, из за этого к тому же меняется сайт и инсталятор. Они также долго переносили часть специально для Windows кода в основной репозиторий git'а чтобы упростить поддержку его.
У них и новый web сайт git-for-windows.github.io. Вот milestone для первого релиза Git for Windows (теперь будет так называться вместо Msysgit)
У них и новый web сайт git-for-windows.github.io. Вот milestone для первого релиза Git for Windows (теперь будет так называться вместо Msysgit)
Спасибо за новость! На Мак всё встало из исходников как надо!
Ну через хуки можно было и раньше настроить деплой после пуша, и более того, можно указывать внешнюю директорию, чтобы в корне не лежал
.git
.А кстати, что там сейчас с TortoiseGit (под виндой)? Раньше было все аналогично TortoiseSVN и TortoiseHg, а начиная с какого-то момента он перестал встраиваться в контекстное меню (или только у меня так?), зато сам git начал встраивать туда какие-то пункты…
Я правильно понимаю, что push to deploy — это возможность пуша в не-bare репозиторий?
А git branch -d --force тоже самое, что и git branch -D раньше?
А git branch -d --force тоже самое, что и git branch -D раньше?
Я могу ошибаться, а разве были какие-то проблемы с push'ем в не-bare репозиторий? Насколько я помню, bare репозиторий нужен чтобы не хранить лишние файлы working copy на сервер где никто с этими файлами не работает. Или там какая-то еще механика?
До 2.3 можно настроить варнинги и запретить пушить в текущую ветку не-bare репозитория с помощью "'receive.denyCurrentBranch" — чтобы не повредить незакомиченные изменения, так как поменяется HEAD.
Да, --force делает то же самое что и -D, это написано в справке.
До 2.3 можно настроить варнинги и запретить пушить в текущую ветку не-bare репозитория с помощью "'receive.denyCurrentBranch" — чтобы не повредить незакомиченные изменения, так как поменяется HEAD.
Да, --force делает то же самое что и -D, это написано в справке.
Ну да, точнее по-умолчанию он и запрещал пушить в бранч, «зачекаученный» в удаленном не-бэр репозитории.
Я понял, прикольная фича получилась. Даже наверное не столько для деплоя, сколько для совместной работы — пушишь свои изменения коллеге прямо в репо, он их сразу использует (если у вас разные репозитории).
Я понял, прикольная фича получилась. Даже наверное не столько для деплоя, сколько для совместной работы — пушишь свои изменения коллеге прямо в репо, он их сразу использует (если у вас разные репозитории).
git clone --reference ../oldclone --dissociate https://github.com/gitster/git.git
Киллер-фича для ядер линукса и многих других проектов-мамонтов.
# Вот это теперь не сработает — разработчик явно хочет сделать push в 'experimental', а не в 'master'.
git push
Поставьте пожалуйста коммент на одной строчке с командой, чтобы точно определить «Вот это»
Sign up to leave a comment.
Вышел git 2.3