GitСинхронизация форкнутого репозитория с оригинальным

Очередная заметка для самого себя, чтобы не искать. Вроде бы всё до ужаса элементарно, но не запомню, пока не напишу об этом :)

Первым делом добавляем remote-репозиторий, ссылающийся на оригинальный, назовём его, к примеру upstream1. Список удалённых репозиториев можно посмотреть командой git remote -v, чтобы убедиться, что всё верно.

После вытягиваем все изменения, произошедшие в репозитории upstream2 и сливаем их со своим репозиторием3.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# шаг 1

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

# шаг 2

git fetch upstream

# шаг 3

git checkout master
git merge upstream/master
git prompt

GitТекущая ветка в командной строке

Объяснял и показывал сабж уже четырём человекам, по меньшей мере, поэтому сделаю запись и буду скидывать ссылку. Хотя таких записей в интернете уже пруд пруди на всех языках :)

git diff colors incorrectly

Gitgit diff и FreeBSD

В общеобразовательных целях решил поиграться с FreeBSD и, естественно, установил туда Git. Настроил, как положено, вывод цветов в консоль, т.е.:

1
git config --global color.ui true

И, вроде бы, всё хорошо, однако при использовании команды git diff вывалилась такая печалька на экран.

Решение нагуглилось секунд за 30. Нужно всего лишь установить в конфигурации Git-а правильный пейджер.

1
git config --global core.pager 'less -R'

Вот, собственно, и всё. Можно было и не писать этого всего, но должны же быть тут какие-то заметки :)

composer transportexception

Контроль версийComposer TransportException, проблемы с загрузкой пакетов.

Иногда так бывает, что composer не может стянуть вендорские файлы. Тут даже и сам композер совершенно не при чём, может валяться github, например, или другой ресурс, где необходимый пакет размещается.

Собственно, вылазит ошибка вида:

1
2
[Composer\Downloader\TransportException]
The "https://api.github.com/repos/bla-bla-bla/zipball/v6.6.6" file could not be downloaded (HTTP/1.1 404 Not Found)

До сегодняшнего дня я просто выжидал, пока очнётся ресурс, откуда должен скачаться пакет, однако на этот раз мне не повезло, поскольку два вечера подряд я наблюдал одно и то же сообщение (хотя утром в другом проекте библиотеки скачались как по маслу, просто забыл под шумок стянуть и других вендоров, повисших в неопределённости). Пришлось лезть в гугл и искать. И оно того стоило, поскольку первая же ссылка указала решение.

1
php composer.phar install --prefer-source

Данная опция указывает composer-у, что необходимые файлы должны извлекаться непосредственно из исходников в репозитории системы управления контроля версиями, а не из подготовленного пакета (по умолчанию для стабильных версий). Собственно, всё. Больше информации здесь

SVNВнешние зависимости SVN

Данной записью открываю тег заметки, по которому буду описывать некие элементарные (или базовые) вещи скорее для себя, так что многие тут ничего волшебного не увидят.

С системой управления версий SVN работаю уже года полтора и, честно говоря, уже не представляю, как программировал до этого, но вот на внешние зависимости в svn наткнулся недавно. Суть в том, что файлы в одном каталоге подтягиваются системой из другого каталога или вообще из другого репозитория.

В частности, можно таким образом заполнять папку library, содержащую внешние библиотеки. Ниже пример с зендом (ради ссылки, собственно, весь пост и городится)

1
2
~$ svn propedit svn:externals library
http://framework.zend.com/svn/framework/standard/tags/release-1.12.0/library/Zend Zend

Ранее я либо коммитил внешние библиотеки в репозиторий, либо выставлял игнорирование на всё содержимое папки библиотек, а для обновления библиотек делал всё, как в каменном веке, т.е. сносил одни папки, скачивал и распаковывал другие, отправлял их в хранилище по новой и т.п. Теперь достаточно отредактировать свойство svn:externals

Кроме всего прочего, можно явно указать номера ревизий для внешних зависимостей. Это позволит избежать сюрпризов со стороны внешних хранилищ, когда после очередного обновления проект ломается, ведь код на внешних хранилищах, как правило, вам не подконтролен. Делается это приблизительно так.

1
2
~$ svn propedit svn:externals library
http://framework.zend.com/svn/framework/standard/tags/release-1.12.0/library/Zend@4321 Zend

P.S. Есть, конечно, и более новомодные штуки, вроде composer, но и до него руки дойдут уже скоро :)

IDENetBeans + TortoiseSVN 1.7

Обновил недавно черепашку до версии 1.7 и стал регулярно получать сообщение об ошибке в среде разработки NetBeans, т.к. тамошний клиент для работы с Subversion пользуется метаданными рабочей копии по версии 1.6

Залез в гугл и отыскал решение этой проблемы. Необходимо в файле .../etc/netbeans.conf добавить параметр -J-DsvnClientAdapterFactory=commandline в опцию netbeans_default_options

В настройках IDE можно явно указать путь к клиенту Subversion. Делается это в Сервис → параметры → Разное → Управление версиями (Tools → Options → Miscellaneous → Subversion)