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 ()

при которой изменения отправляются только из текущей ветки в ветку с тем же именем

наконец-то

crono
()

Хотеть git без проблем с кодировками на венде.

Конфиги им архивировать просто волшебно...

AVL2 ★★★★★
()

Git 1.8.0? Good!

/me свистнул и полетел обновляться.

anonymous
()

новость есть а ебилда нет. непорядок пасаны

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

Хотеть git без проблем с кодировками на венде.

Так же давно.
С версии 1.7.10 для внутреннего представления используется UTF-8 а клиент сам конвертирует в кодировку ФС. у msysgit уже нет проблем.

German_B
()

Git явно писался не для людей. На мой взгляд лучше выбирать то, что делает то же самое, но лучше и удобнее. Mercurial наше всё :)

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

Ну так и нечего его использовать в других проектах. Писалось для разработки ядра Linux — так пускай там и используется. Для более популярных сценариев не особо юзабельно. Mercurial как-то больше для людей писался. А то получается, что мыши плакали, кололись, но продолжали грызть кактус.

VEG
()

Между Debian и DragonflyBSD точно не должно стоять запятой?

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

пробовал многократно.

Хочется, чтобы из вёнд и линукса везде русский был. В логах, в именах файлов и т.д. Это реально тяжко, учитывая, чтов линуксе везде utf-8, а в венде где-то в логах cp1251, в именах файлов cp866, а где-то и utf-8. Реально бедлам.

Нужна метода ведения репа.

AVL2 ★★★★★
()

проблему с кодировками под вендой пофиксили?

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

Странно. У нас такой проблемы на работе не наблюдается

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

Хотеть git без проблем с кодировками на венде.

лехко

kto_tama ★★★★★
()

git rulezz, Линус красавчег.

insider ★★★
()

Краткое содержание треда:

- Гиииит-гит-гит-гит-гит-гит!
- Хэгэ! Хэгэ! Хэгэ!

Cancellor ★★★★☆
()

Анонсирован релиз распределенной системы управления исходными текстами

А что, туда только текстовые файлы засунуть можно? А бинарники с данными можно?

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

А что, туда только текстовые файлы засунуть можно? А бинарники с данными можно?

Вообще, можно. Но работать будет не очень, особенно если бинарники большие. Для таких случаев лучше подходит svn, или largefile из hg.

anonymous
()

Гит, конечно, весь какой-то черезжопный. Даже на гитхаб приходится ходить hg-git-ом.

Но ваш спор о длине команд просто смешон. Зачем частые команды в консольке-то набирать, когда в редакторе есть хоткеи? А как диффы смотреть, тоже в терминале вечно запускать scm diff? Поехавшие.

Sphinx ★★☆☆
()
Последнее исправление: Sphinx (всего исправлений: 1)

От себя: я сам пользуюсь mercurial ввиду некоторой специфики моей деятельности, но мне интересен также и git. Кто-нибудь знает — прилетит ли он в Fedora 17?

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

Но ваш спор о длине команд просто смешон.

Надо ж было о чем-то поспорить, чем не повод? ;) К тому же в нем есть доля истины.

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

А как диффы смотреть, тоже в терминале вечно запускать scm diff?

Ну есть же люди, которые предпочитают vim/emacs вместо eclipse. Так почему бы не использовать в консоли hg diff вместо вжик-клик-вжик-клик-клик-вжик-клик? ;)

К тому же если включить color = в .hgrc, то hg diff выглядит довольно неплохо.

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

Ну есть же люди, которые предпочитают vim/emacs вместо eclipse.

eclipse тормозит до такой степени, что вообще не понятно как кто-то может его использовать и выносить его тормоза.

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

Хочется, чтобы из вёнд и линукса везде русский был. В логах, в именах файлов и т.д.

Русский в логах и именах файлов - быдлокодерство

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

в гите вообще всё неочевидно и сложно

Но если понять суть(тм), все становится очевидно и просто

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

Для таких случаев лучше подходит svn, или git annex

Fixed ftgj.

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

Mercurial недолюбливаю, ибо там нет аналога git add + git diff --cached.

Меня наоборот, это в git раздражает. До сих пор не могу понять, нафига нужен index? Если нужно частично зафиксировать изменения то есть hg record vim+:AuRecord. Для чего ещё может быть нужен index я совершенно не понимаю.

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

Вимеры тоже наверняка уже VC воспроизвели в своей пищалке.

Нет, это git воспроизвёл VC в нашей пищалке: git config --global diff.tool vimdiff

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

Для чего ещё может быть нужен index я совершенно не понимаю.

Гит так устроен. Индекс - часть репозитория.

Каждый commit состоит из набора файлов в репозитории (он же index), файла с метаданными, который содержит указатели на эти файлы, файла с указателем на метаданные и на предыдущий commit. Таким образом можно откатиться на любой commit. Commit можно делать либо в 2 шага, либо в 1. По-умолчанию 2.

Вот здесь, на первой картинке наглядно нарисовано:

http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is

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

Русский в логах и именах файлов - быдлокодерство

Внезапно, файлы бывают не только с исходным кодом. А заставлять людей извращаться с латинницей, вместо того, чтобы писать на родном языке и называть файлы как они хотят — истинное быдлокодерство.

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

Для чего ещё может быть нужен index я совершенно не понимаю.

Гит так устроен.

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

git commit
(и надстроек над ним)? Зачем мне думать о том, что какие‐то изменения есть в index (staging area) (и они будут зафиксированы при
git commit
), а какие‐то ещё только в рабочем каталоге (часть из них будет зафиксирована при
git commit -a
)?

Кроме того, в mercurial есть

hg commit --addremove
, в git без дополнительной мороки нет.

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

Зачем мне думать о том, что какие‐то изменения есть в index (staging area), а какие‐то ещё только в рабочем каталоге

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

hg commit --addremove, в git без дополнительной мороки нет.

Если я правильно понял, тебе нужен «git add -A».

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

Зачем мне думать о том, что какие‐то изменения есть в index (staging area), а какие‐то ещё только в рабочем каталоге

Нет гарантии, что именно ты внёс изменения

Пошел коммитить, и только тогда правильно понял вопрос. Не все изменения есть смысл одним махом заносить в коммит - часто надо разбить их на два-три коммита, а часть вообще попридержать.

LamerOk ★★★★★
()

Вот это в треде троллей полегло!

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

Гит, конечно, весь какой-то черезжопный. Даже на гитхаб приходится ходить hg-git-ом.

Atomic facepalm. В машину ты тоже на лошади заходишь?

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

А зачем эти два шага?

Они физически выполняются, хочется кому-то этого или нет. Концепция такая у системы.

Что мешало авторам добавлять в index только и исключительно при git commit

А зачем? Есть опция -a, хочешь - пользуйся, не хочешь - не пользуйся.

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

Код в вёндах, вот что быдлокодерство. А руссский в именах файлов и логах, это норма, когда в гите разные там документы, картинки и все такое.

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

Есть такое. Git не для людей, а для программистов.

<нытьё неосилившего hg> У Mercurial вот обратная проблема — он для людей, а не для программистов. В git, освоив базовую арифметику, я могу проделывать весьма хитрые операции над коммитами, не боясь потерять историю.

А в Mercurial как? Патчи против апстрима, значит, предлагается держать в MQ. Но потом вдруг оказывается, что rebase нормально делать не получится. rebase для MQ патчей судя по всему не умеет делать нормальных 3-х точечный merge. Как патч распилить на два — тоже не очень понятно. В туториале предлагают какие-то рукапашные махинации с диффами. Как эти патчи потом разделять в коллективе — хрен его знает.

Можно, конечно, обычными ветками обойтись. Вариант. Но опять же, если я делаю патчи против апстрима, я хочу их постоянно причёсывать, чтоб они выглядели аккуратненько и чтоб при следующем rebase на новую апстрим-версию их было легко и прятно мёрджить. hg rebase, конечно, спасает, но какой-то он слабенький супротив git-овского.

Про то, что для логического понятия «ветка» миллион разных вариантов тоже промолчу.

Чуть накосячишь, начинаются проблемы, как удалить лишнюю ревизию, голову, ветку, и.т.д. При этом все эти операции — весьма опасны. В git надо очень постараться, чтобы потерять работу. Ну т.е напортачить гораздо легче, но и восстановаться после ошибки просто. </нытьё неосилившего hg>

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

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

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

«git commit -a», считаю, вредная команда. Она, конечно, удобна для новичков, которым главное свой хлам вбросить в репозиторий, но создаёт ложное впечатление о работе git.

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

hg commit --addremove

git add -A && git commit

Это та самая дополнительная морока?

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