Анонсирован (https://lkml.org/lkml/2012/10/21/158) релиз распределенной системы управления исходными текстами Git 1.8.0 (http://git-scm.com/). Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6... Android (https://android.googlesource.com/), Libreoffice (http://cgit.freedesktop.org/libreoffice), Systemd (http://cgit.freedesktop.org/systemd), X.Org (http://cgit.freedesktop.org/xorg), Wayland (http://cgit.freedesktop.org/wayland), Mesa (http://cgit.freedesktop.org/mesa/), Gstreamer (http://cgit.freedesktop.org/gstreamer), Wine (http://source.winehq.org/git/wine.git), Debian (http://anonscm.debian.org/gitweb) DragonFly BSD (http://gitweb.dragonflybsd.org/?p=dragonfly.git;a=summary), Perl (http://perl5.git.perl.org/perl.git), Eclipse (http://git.eclipse.org), GNOME (http://git.gnome.org/browse/), KDE (https://projects.kde.org/projects), Qt (http://qt.gitorious.org/), Ruby on Rails (https://github.com/rails/rails), PostgreSQL (http://git.postgresql.org/gitweb/), VideoLAN (http://git.videolan.org), PHP (http://git.php.net/).Переход от серии версий 1.7.x к 1.8.x обусловлен изменением поведения команды "git push". В ситуации когда при выполнении "git push" явно не указано что именно помещать в репозиторий в прошлых выпусках использовалась семантика "matching", при которой для обновления выбирались все внешние ветки и теги с именами, совпадающими с локальными. Начиная со следующего выпуска (1.8.1) поведение будет изменено и по умолчанию будет применяться семантика "simple", при которой изменения отправляются только из текущей ветки в ветку с тем же именем, в случае если локальная ветка назначена для интеграции с удалённой веткой. Переопределить новое поведение можно через конфигурационную переменную "push.default".
Из других изменений в Git 1.8.0 можно отметить:
- Команда "git branch --set-upstream" объявлена устаревшей и может перестать работать в будущих выпусках. В качестве замены представлена команда "git branch [-u|--set-upstream-to]". Ранее были не редки случаи указания "git branch --set-upstream origin/master", что приводило к созданию локальной ветки "origin/master" для интеграции с текущей загруженной веткой, что явно не то что подразумевал пользователь. Окончание "-to" поможет исключить ошибочную трактовку назначения опции;
- В "git svn" обеспечена поддержка работы с SVN 1.7. В "git p4" добавлена опция "--conflicts" для определения действий в случае обнаружения конфликта при выполнении "p4 submit";
- В состав включена собственная реализация библиотеки регулярных выражений для платформ, на которых наблюдаются проблемы с работой библиотеки regexp. Также добавлены обвязки для обеспечения совместимости с нестандартными реализациями mkdir и setitimer();- В парсер опций "git checkout" добавлена проверка типичных ошибок в порядке задания параметров командной строки. Например, при выполнении "git checkout -b -t foo bar" будет указано, что вместо имени ветки указана опция "-t";
- Внутренние вызовы "git merge-base" заменены на более упрощённые аналоги, выполняющие только проверки наложения коммитов, без более ресурсоёмких проверок слияний веток;
- Для платформ Win32 и GNOME добавлены хелперы для доступа к ключам текущего пользователя;
- Выполнено начальное портирование для операционной системы серверов HP NonStop (http://en.wikipedia.org/wiki/NonStop);- При выполнении "git am" теперь из строки "RE: subject" вырезается и префикс "RE:", а не только "Re:" и "re:";
- В команду "git cherry-pick" добавлена опция "--allow-empty-message" для повторной отправки коммита без занесения сообщений в лог;
- В команду "git daemon" добавлена опция "--access-hook", разрешающая внешним командам доступ к сервисам проверки по IP или пути к репозиторию.
- В команде "git difftool --dir-diff" реализована поддержка использования символических ссылок для подготовки временной копии рабочего дерева;
- В команду "git grep" по умолчанию добавлена возможность указания нестандартных типов масок;- В команде "git log -g" появилась опция "--grep-reflog=pattern" для ограничения вывода с использованием фильтра по маске;
- В команду "git merge-base" добавлена опция "--is-ancestor A B", позволяющая проверить является ли А прародителем B;
- В команду "git rebase -i" добавлена опция "--edit-todo" для написания инструкций по дальнейшим изменениям;
- Через переменные конфигурации mergetool.$name.cmd теперь можно переопределить любые команды для "git mergetool", в том числе и встроенные;
- Интегрированы накопившиеся изменения для "git gui".
URL: https://lkml.org/lkml/2012/10/21/158
Новость: http://www.opennet.ru/opennews/art.shtml?num=35136
Правильно push подкрутили, довольно нелогично оно себя вело
> довольно нелогично оно себя велоКогда пользователи других DVCS указывают «git ведёт себя нелогично» — они неосиляторы и виндузятники. Но когда это же признают разработчики git и вносят соответствующие изменения — это же Совсем Другое Дело.
Не смешивайте всё в одну кучу.
Пользователи других DVCS слишком часто кричат о нелогичности, не удосужившись прочесть книжку/мануал/хауту, и не поняв *концепций.*
Ага, я понял. То-то я смотрю, что Git supporters, как один, не только удосужились почитать маны по прочим DVCS, но и попользовались ими в реальных проектах, чтобы как следует аргументировать своё мнение по вопросу превосходства Git над прочими жалкими поделками.
А разве что бы понять что автомобиль лучше, обязательно надо перед этим поездить на лошади, ишаке, осле, корове и свинье?
Да и использовать DVCS, главным преимуществом которой называется ... красивый GUI, это просто извините.
наглядная иллюстрация не заставила себя ждать> использовать DVCS, главным преимуществом которой называется ... красивый GUI, это просто извините.
если речь о mercurial, то помимо GUI (сторонней разработки, которой лично я, например, практически не пользуюсь) в преимущества я бы ещё записал (навскидку) человеческий CLI, revsets, +2 способа ветвления ревизий, защита от случайной перезаписи чужих изменений, полноценный API расширений (позволяющий реализовывать совсем святотатственные вещи вроде прозрачной работы с репозиториями git или эффективного хранилища для блобов). Но, действительно, вам-то откуда такое знать — этого же не пишут на whygitisbetterthanx.com.
всем безусловно было очень полезно прочитать пространный анализ причины слива других систем контроля версий, спасибо.
ЧТОБЫ понять
О, великий осилятор! Поведай, сколько вариантов поведения имеет приведенный кусок в зависимости от содержимого origin и схерали поведение неоднозначное?$(GIT) checkout $(REV)
$(GIT) branch $(BRANCH)
> они неосиляторы и виндузятники.Палитесь :)
Да собственно они просто поменяли дефолтное значение. Ничто не мешает сделать на старом гите git config --global push.default simple и получить то же самое.
вообще оно так уже с 1.7.х
> старом гите git config --global push.default simple и получить то же самое.Ну так "неосиляторы и виндузятники" этого не знают. Ибо на то и неосиляторы :)
> для платформ, на которых наблюдаются проблемыВ виду того, что в Git простой мэйкфайл, подозреваю, что они проверяют типа `uname`, а это лажа.
P. S. менять кавычки - то же лажа (` -> ')
>P. S. менять кавычки - то же лажа (` -> ')Писать слово "тоже" как "то же" - тоже лажа
> Писать слово "тоже" как "то же" - тоже лажаТо же ла жа. Так логичнее :)
> Переход от серии версий 1.7.x к 1.8.x обусловлен изменением поведения команды "git push".НЕ правда!
Внимательно читаем первое предложение
https://raw.github.com/git/git/master/Documentation/RelNotes...
In the next major release (not *this* one), we will change the
behavior of the "git push" command.