LINUX.ORG.RU

Git 1.8.0

 , ,


0

0

Анонсирован релиз распределенной системы управления исходными текстами Git 1.8.0. Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, Android, Libreoffice, Systemd, X.Org, Wayland, Mesa, Gstreamer, Wine, Debian DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, PostgreSQL, VideoLAN, PHP.

Переход от серии версий 1.7.x к 1.8.x обусловлен изменением поведения команды «git push». В ситуации когда при выполнении «git push» явно не указано что именно помещать в репозиторий в прошлых выпусках использовалась семантика «matching», при которой для обновления выбирались все внешние ветки и теги с именами, совпадающими с локальными. Начиная с ветки 1.8 поведение изменено и по умолчанию будет применяться семантика «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;
  • При выполнении «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».

>>> Новость взята с OpenNet.RU

★★★

Проверено: tazhate ()
Ответ на: комментарий от WFrag

А зачем эти два шага? Как я понял, то, что здесь делается — это сбор (staging) содержимого следующего изменения — добавление в index.

Весьма полезно при rebase и merge, да и при обычном commit тоже. Позволяет интерактивно набирать изменения, которые хочешь закоммитить и контролировать эти изменения.

Особенно «полезно» то, что проверить, что результат такого коммита хотя бы собирается, без изврата нельзя вообще никак. Закинул в стейдж черт знает что, закоммитил и совесть спокойна, содержимое working copy ведь работает!

n15n
()
Ответ на: комментарий от n15n

Особенно «полезно» то, что проверить, что результат такого коммита хотя бы собирается, без изврата нельзя вообще никак. Закинул в стейдж черт знает что, закоммитил и совесть спокойна, содержимое working copy ведь работает!.

А оно почти всегда так. Я редко видел, чтобы разработчики подчистую всё коммитили. Постоянно какие-то изменения локальные, да висят. Типа принтов дебажных каких-нибудь в левых файлах.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

Постоянно какие-то изменения локальные, да висят. Типа принтов дебажных каких-нибудь в левых файлах.

В mercurial я сделаю так:

hg qadd -i debug_stmts.patch # добавляем в патч ненужные изменения
hg qpop # убираем патч куда подальше
# проверяем, что в working copy все ок, коммитим
hg qpush # возвращаем локальные изменения

А в гите как предложите с этим бороться?

n15n
()
Ответ на: комментарий от n15n

Особенно «полезно» то, что проверить, что результат такого коммита хотя бы собирается, без изврата нельзя вообще никак. Закинул в стейдж черт знает что, закоммитил и совесть спокойна, содержимое working copy ведь работает!

Именно поэтому у меня hook, тестирующий последнее изменение в default ветке перед отправкой на удалённый сервер. Самое интересное — в git такого хука нет! Только на входящие изменения. Если дело идёт о работе, где удалённый сервер свой, то это нормально. А если это мой мелкий проект на bitbucket, а тесты работают довольно долго (и я иногда хочу фиксировать изменения, которые их проваливают), то нет.

ZyX
()
Ответ на: комментарий от n15n

А в гите как предложите с этим бороться?

Коммитим нужное
$ git add ...
$ git commit ...

прячем ненужное:
$ git stash

проверяем, что всё работает. Если нет, то правим и потом разово:
$git commit -a --amend

Пушим коммит:
git push ...

возвращаем локальные изменения:
$ git stash pop

А вообще хорошая практика держать такие локальные изменения в отдельном собственном бранче и потом просто черри-пикать коммиты в основную ветку разработки (с последующим ребайзом своей ветки).

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

Коммитим нужное $ git add ... $ git commit ...

прячем ненужное: $ git stash

проверяем, что всё работает. Если нет, то правим и потом разово: $git commit -a --amend

Пушим коммит: git push ...

возвращаем локальные изменения: $ git stash pop

Или просто пишем скрипт, который берёт ревизию в качестве аргумента и проводит тестирование с ней.

Потом можно его скармливать hg bisect, особенно если написать так, чтобы он мог брать тест из рабочей копии, а остальное из данной ревизии. Правда у меня функциональные тесты и в отдельных файлах.

ZyX
()
Ответ на: комментарий от ZyX

Или просто пишем скрипт, который берёт ревизию в качестве аргумента и проводит тестирование с ней.

Да, такое без проблем:
git checkout <ShaCommitId>
и можно скриптовать сколько душе угодно

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

http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
git bisect run <cmd>...

Короче, спорить в общем-то не о чём. И git, и hg одинаково эффективно выполняют задачи по управлению историей файлов, хоть и делают это немного разными путями и командами.
Тут уже спор идёт на уровне «синий цвет фу» вместо «материал прочнее/слабее». Потому что «материал» одинаково прочен у обоих, поэтому начинаются споры про «эргономичность», «сложность», «порог вхождения» и т.д.

Скажем так, новичку абсолютно без разницы в чём не разбираться: или он не будет знать Git, или он не будет знать Mercurial - в обоих случаях шансы на путь к успеху равны :) В конечном итоге получится адепт гита или ртути, но только лишь в силу привычки.

Slavaz ★★★★★
()
Последнее исправление: Slavaz (всего исправлений: 1)
Ответ на: комментарий от Slavaz

Да, такое без проблем: git checkout <ShaCommitId> и можно скриптовать сколько душе угодно

Это замечание не было описанием преимущества git или mercurial (в отличие от замечания про хуки, набор которых у git очень беден). Просто странно слышать от народа о проблеме вроде «версия в рабочем каталоге работает, а что зафиксировали — ХЗ». А потом весьма неудобный способ решения проблемы от вас.

Если надо что‐то сделать со старой версией один раз — то нормально. А проводить так регулярно тестирование…

ZyX
()
Ответ на: комментарий от Slavaz

Скажем так, новичку абсолютно без разницы в чём не разбираться: или он не будет знать Git, или он не будет знать Mercurial - в обоих случаях шансы на путь к успеху равны :) В конечном итоге получится адепт гита или ртути, но только лишь в силу привычки.

На уровне pull/commit/push — да. На чём‐то большем выясняется наличие у mercurial API и лучшей системы хуков. Плюс выпячивание некоторых деталей реализации у git и слишком подробная справка.

API и хуки мне важны, без остального, что я видел в качестве преимуществ git я легко обхожусь.

ZyX
()
Ответ на: комментарий от n15n

В git'е с этим можно бороться так же (через механизм git stash), а можно просто не добавлять ненужные изменения в ченджсет.

Вообще, на самом деле, позицию «отрицателей удобства git add -i» можно довести до абсолюта: дерево исходников представляет из себя целостную сущность. Соответственно, возможность выбирать файлы в коммит - в принципе лишняя: надо просто коммиттить всё изменённое, а если кому что не нравится - всегда есть возможность сделать diff -u и отредактировать его руками.

По-моему, я не сильно преувеличил, а? ;)

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.