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 ()
Ответ на: комментарий от anonymous

Что, вообще говоря, вполне логично. :)

Это настолько же логично, насколько и нелогично. И всегда неудобно.

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

Не пойму, чем это удобней git-show-branch?


Эта не слишком информативна. И у меня, и в куче других проектов, которые я видел (не во всех конечно) (по понятным причинам, большинство проектов, которые я видел, на git), первая строчка сообщения не является кратким описанием всех изменений. Кроме того, не видно автора и даты.

Насчёт автора и даты - это да. А вот, по поводу неинформативности первой строки - она как бы для этих целей и сделана. Если придерживаться этого её назначения - будет удобнее.

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

А, вообще, где-нибудь есть таблица, где бы описывались команды mercurial и аналогичные в git?

Очень сложно сделать правильную таблицу. Например, “hg grep” будет аналогом “git log -S”, “git grep” или вообще не иметь анологов — в зависимости от ключей запуска. Причём под последний пункт подпадает простейшее “hg grep pattern” — к этому варианту нет аналогов. Или я их не знаю.

“git checkout” выполняет работу “hg update”, “hg revert” и “hg bookmark”. “git checkout --orphan branchname” не имеет аналогов в mercurial (ну или я их не знаю). И так ко многим командам.

+ ещё надо сравнивать mercurial revsets vs git revisions.

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

Насчёт автора и даты - это да. А вот, по поводу неинформативности первой строки - она как бы для этих целей и сделана. Если придерживаться этого её назначения - будет удобнее.

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

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

можно помещать в индекс и наоборот без всяких плагинов

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

git add --update не?

Это уже как минимум третий ответ, советующий «git add».

«git add» не фиксирует изменения. Он только добавляет в index. Более того, с -A он добавляет обратно в index то, что оттуда было явно удалено. С -u он не добавляет неизвестные файлы. В mercurial с --addremove появляется разница только и только для неизвестных и отсутствующий файлов.

То, что мне надо должно добавлять неизвестные файлы, удалять отсутствующие файлы, забывать забытые и удалённые и фиксировать изменения в изменённых. «git commit -a» справляется только с удалёнными, изменёнными и добавленными. Про «git add» я написал выше. Получается, если у меня есть список файлов, в котором есть файлы почти любого статуса (неизвестные, добавленные, изменённые, удалённые, отсутствующие), то мне нужно знать, какой статус имеет каждый из них перед тем, как делать «git add», «git commit» или что‐то ещё.

PS: Я где‐то ранее говорил про то, что «git add -A» почти подходит, просто он не умеет фиксировать изменения. Это не так, я просто поленился проверить. Конкретные претензии см. выше.

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

Как выполнить аналогичный workflow в git?

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

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

А какой будет аналог в гите? Три pull-а он сделать не даст, на втором pull-е будет merge-конфликт, и до третьего pull-а дело просто не дойдет. Делать три fetch-а? ;) И как потом увидеть heads? Как выполнить аналогичный workflow в git?

Когда вы будете брать изменения у childN, то вы сделаете так:

$ git remote add child1
$ git remote add child2
$ git remote add child3

после чего

git fetch --all

А теперь можно увидеть много веток, которые гит уже создал автоматом:

$ git branch -a
* master
  remotes/child1/master
  remotes/child2/master
  remotes/child3/master

А далее, как сами хотите или git merge child1/master или git merge child2/master или в принципе не мержите.

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

ещё один не владеет матчастью

rebase в hg так и называется, перетасовывание коммитов делает искаробочный плагин histedit

а MQ позволяет сложить патчи под контроль версий и делиться ими.

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

перетасовывание коммитов делает искаробочный плагин histedit

только он ущербный: либо оставляет весь хлам, либо ничего, т.к. gc нету

а MQ позволяет сложить патчи под контроль версий и делиться ими.

для этого есть гитовые ветки и git format-patch

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

gc нету

зачем gc в VCS, которая не делает вид, будто некоторые (не принадлежащие никакой ветке) коммиты не существуют?

для этого есть гитовые ветки и git format-patch

вот же тупые эти разработчики gitum и stgit, да.

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

зачем gc в VCS, которая не делает вид, будто некоторые (не принадлежащие никакой ветке) коммиты не существуют?

В mercurial нет изменений, не принадлежащих никакой ветке. Просто нет: если «hg log» не показывает ветку это всего лишь означает, что используется ветка «default».

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

В mercurial нет изменений, не принадлежащих никакой ветке

я хотел сказать, что в git-то они есть. и porcelain старательно пытается делать вид, что их не существует.

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

вот же тупые эти разработчики gitum и stgit, да.

ага, неосиляторы

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

Можно и в репозитории оставлять, пока по умолчанию их не видно в логе. Да, и наследоваться от этих коммитов нельзя.

Так вот, поскольку в mercurial возможны многоголовые ветки, то развидеть старые коммиты он не может, а поэтому оставлять старые версии коммитов в репозитории нельзя. поэтому на них после rebase автоматически (и опционально) натравливается команда strip, которая и сбрасывает бэкапы на диск.

Ну и да, скорее всего с релизом http://mercurial.selenic.com/wiki/ChangesetsObsolescence нужда в бэкапах отпадёт.

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

А куда по-твоему надо девать старые версии коммитов, оставшиеся после ребейза?

Удалять сразу? Можно ещё делать резервные копии, как делает «hg strip». Но никто в mercurial не пытается притвориться, что их не существует или сделать процедуру окончательного удаления настолько неочевидной.

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

Удалять сразу?

Не вариант, что если я захочу откатить изменения

Можно ещё делать резервные копии

Звучит лучше. Я надеюсь, они хранятся в самом репозитории?

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

Я надеюсь, они хранятся в самом репозитории?

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

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

Звучит лучше. Я надеюсь, они хранятся в самом репозитории?

Не совсем. В .hg/strip-backup.

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

Вот ненавижу это высокомерное. Можно ли считать JavaScript кодера программистом? Можно ли считать PHP кодера программистом? Можно ли считать Java кодера программистом? Можно ли считать C# кодера программистом? Можно ли считать Delphi кодера программистом? Можно ли считать C++ кодера программистом? Можно ли считать C кодера программистом? Можно ли считать ASM кодера программистом? Или программисты — это только те, кто пишет сразу в машинных кодах? :) И самый главный вопрос. Если программисты уже не люди, то они сверхлюди или недолюди?

VEG
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.