LINUX.ORG.RU

Git 2.7.0

 


0

3

Команда разработчиков Git рада сообщить о релизе Git 2.7.0.

Этот выпуск содержит более 800 коммитов от 81 автора, 26 из которых не так давно присоединились к проекту.

git bisect теперь не только для регрессий

Несмотря на то, что git bisect наиболее часто используется для поиска регрессий, такой подход может быть применён при поиске любых других изменений. Какие бы изменения вы не искали, вы отмечаете хорошими ревизии до изменений и плохими после. Это может путать, особенно, если вы хотите найти коммит, исправляющий ошибку. Чтобы решить эту проблему, добавлена возможность вместо good и bad использовать свои собственные термины. Без дополнительных настроек можно использовать более нейтральные термины old и new:

$ git bisect start
$ git bisect old v4.2
$ git bisect new master

Указать свои собственные термины можно следующим образом:

$ git bisect start --term-old yucky --term-new yummy
$ git bisect yucky v4.2
$ git bisect yummy master

Новый параметр конфигурации для --recurse-submodules

Если вы используете субмодули, то вероятно совершали ошибку при отправке изменений в главный модуль без первоначальной отправки соответствующих изменений в субмодули. Надо было указывать опцию --recurse-submodules, например:

$ git push --recurse-submodules=on-demand origin

Теперь вы можете задать такое поведение по умолчанию с помощью нового параметра конфигурации:

$ git config push.recurseSubmodules on-demand

Если вы предпочитаете, чтобы Git предупреждал о потенциальных проблемах, используйте:

$ git config push.recurseSubmodules check

Дальнейшее совершенствование worktree

Помните команду git worktree, которая была введена в Git 2.5.0? Она позволяет создавать множественные рабочие копии, которые связаны с одним локальным репозиторием Git.

В Git 2.7.0, git worktree продолжает улучшаться:

  • Новая команда git worktree list позволяет получить список рабочих копий, связанных с текущим репозиторием.
  • git bisect теперь может запускаться в любом worktree, или даже в двух одновременно.
  • Вы теперь можете клонировать из связанного worktree.
  • Улучшена поддержка субмодулей.

Поддержка git LFS для git p4

git p4 является мостом между Git и Perforce, который позволяет получать коммиты из Perforce в Git, отправлять коммиты из Git на сервер Perforce и т. д. (Существуют похожие инструменты для работы с Subversion, Mercurial, Bazaar, TFS, и др.) git p4 теперь может хранить большие файлы в Git LFS («Git Large File Storage»), что позволяет избежать раздувания репозитория на диске. Обратите внимание, что эта функция пока не поддерживает git p4 submit.

Более согласованные команды для получения списка ссылок

В Git есть три основных способа получения списка ссылок: git branch для веток; git tag для меток; и git for-each-ref для ссылок любого типа. Но эти команды, несмотря на их перекрывающуюся функциональность, имели разные возможности и опции.

Теперь, благодаря работе студента Google Summer of Code, Karthik Nayak, эти команды имеют более согласованный интерфейс. Все три команды поддерживают следующие опции:

  • --points-at <object>: получить список ссылок которые указывают на заданный объект;
  • --merged [<commit>]: получить список ссылок, которые были объединены с коммитом (HEAD по умолчанию);
  • --no-merged [<commit>]: получить список ссылок, которые не были объединены с коммитом (HEAD по умолчанию);
  • --contains [<commit>]: получить список ссылок которые содержат указанный коммит (HEAD по умолчанию).

Они также получили новое форматирование и параметры сортировки.

Другие изменения

  • git stash show теперь поддерживает два параметра конфигурации: stash.showPatch и stash.showDiff, которые задают формат вывода по умолчанию.
  • git blame теперь корректно работает с опцией --first-parent, а также, когда --reverse и --first-parent используются вместе.
  • Улучшен внешний вид gitk на high-DPI мониторах.
  • Исправления безопасности [1] [2].

>>> Официальный анонс

>>> Примечания к выпуску

>>> Подробности

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 8)

Ответ на: комментарий от I-Love-Microsoft

Потому что тулкитофобы и пользователи гуёвого гита должны страдать.

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

Спасибо, блеванул. Буду использовать как рвотное средство впредь :)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от nexfwall

Объясните вкратце, в чём соль worktree? Лень парсить маны.

По ссылке из текста новости тоже лень пройтись?

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

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

kirk_johnson ★☆
()

А что означает: «присоединились к проекту?» Фраза просто веет маркетинговым булшитом. Вот я, время от времени, присылаю патчи, провожу (из последнего) в: Qt Creator, FFmpeg, OpenOCD. Я присоединился к этим проектам? Я вот так не считаю. Просто исправляю то, что является багом и мне мешает. Либо добавляю что-то, что может быть полезным не только мне.

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

С точки зрения опенсорса ты полноценный участник проектов. Даже если ты прислал всего один патч. Опенсорс же.

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

Инкрементирую оратора выше. Да и ничего лучше не придумалось. Разве было бы лучше, если бы там было написано «26 из них — новые лица»? Не знаю, мне кажется, что это как-то стрёмно звучит.

Kilte ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

Кто пользуется git? Роботы и киборги?

We Are the GitBorg. You Will be Assimilated. Resistance is Futile.

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

А ты не пользуйся плохой гуйнёй, пользуйся хорошей, которая решает.

Пользоваться гуйней, потому что гуйня?

A1
()

Как славно! Однажды даже использовал.

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

git clone будет делать копии всех файлов данных, или делать на них хард линки

А worktree по другому делает?

и нужно делать push/pull в обе сторны

Это и подразумевалось под «Ну кроме как добавить remote». push в origin, пул из локальной мастер-репы.

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

Выяснишь когда пойдешь работать туда, где это купили и пользуют. А пока не забивай голову.

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

Ой, еще и за деньги...

Да в общем-то были времена, когда покупка VCS за деньги считалась вполне нормальным действием. Тут выше по тексту уже упоминался Rational ClearCase. Он даже был не только под винду, а ещё и под какие-то коммерческие юниксы (сейчас посмотрел - он живой, и под Linux сделали, оказывается). Другое дело, что ClearCase, как правило, покупали не отдельно, а в составе Rational Suite, куда входили ещё ClearQuest, Rose, и ещё что-то, общей стоимостью $11000 за одно рабочее место. Как у многих коммерческих продуктов, сильным местом ClearCase была визуализация - субмодули рисовались разноцветными квадратиками. Больше ничем примечательным он не запомнился.

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

Посмотрел на worktree, крайне полезная фича.

И давно существующая. В 2.7.0 её просто слегка улучшили.

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

Я как бы в курсе. Сейчас стоит вспомнить разве что Perforce, который таки жив и продается. А вот ClearCase'у несколько лет назад End-Of-Life случился, как мне коллеги рассказывали. На сайте IBM написано что-то невнятное, но может быть и так. Версию 7-какую-то перестали поддерживать в 2013м, выпустили 8-какую-то...

ClearCase запомнился например тем, что виндовый клиент умел мапировать репозиторий как диск, и коммит выглядел как «просто скопировать». Ну и конфигспеки там были фееричекские :)

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

Больше ничем примечательным он не запомнился.

Ой ли. Основная фича ClearCase которой нет и не предвидится ни в одной из других существующих VCS(из популярных во всяком случае), это Dynamic View. В случае работы в крупном проекте с кучей разработчиков - крайне удобная штука.

Ну и всякие плюшки типа распределенного мейка, который на крупных, особенно ++, проектах позволяет сократить время сборки на порядки.

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

Гит рулит, остальное на свалку истории.

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

Основная фича ClearCase которой нет и не предвидится ни в одной из других существующих VCS(из популярных во всяком случае), это Dynamic View.

Config Spec писать замучаешься. :)

gns ★★★★★
()

Секьюрити бы джиту не помешало бы добавить... А так верной дорогой идут товарищи! :)

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

Успешный проект на чистом Ц без всяких Пайфонов, Рубей, Жав и ЖавСкриптов

Но с Перлом!

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

Python переезжает на git

шеф-всё-пропало.jpg

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

И это — тоже. Стоит добавить разграничение доступа к отдельным репозиториям или модулям в одном репозитории или ACL какой-нибудь.

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

Основная фича ClearCase которой нет и не предвидится ни в одной из других существующих VCS(из популярных во всяком случае), это Dynamic View. В случае работы в крупном проекте с кучей разработчиков - крайне удобная штука.

+100500

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

Почему не облечь его содержание в достойную форму?

Попробую ответить на ваш вопрос.

Вот допустим они сделали как вы хотели и ещё 5-10 лет назад облекли содержание в достойную форму в виде qt3. Или gtk2. Прошло 5 лет, и им надо переписывать всё под qt4 или gtk3. И тестировать. Пройдёт ещё 5 лет, и придётся... правильно, снова переписывать. Под gtk4 или qt8.

А tk работает и есть не просит. И не ноет «чо ты как лох, у мамки денег на ещё одну планку оперативы не возьмёшь».

Просто для авторов gitk цель - не постоянное писание кода, а работоспособный функционал.

anonymous
()

Сдохните, гребаные костыли.

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

Вот допустим они сделали как вы хотели и ещё 5-10 лет назад облекли содержание в достойную форму в виде qt3. Или gtk2. Прошло 5 лет, и им надо переписывать всё под qt4 или gtk3. И тестировать...

За это время функционал самого продукта немного поменялся, тоже нужно будет лепить обновления - чем это как-то отличается от допиливания до актуального тулкита?

А tk работает и есть не просит.

Так он никому и не нужен. Нет ни одного нормального приложения на tk без которого работа с DE была бы не полноценной. На tk пишут наколеночный шлак который не жалко выкинуть и в разработку которого не хотят вкладываться. gitk в общем то не исключение, он неудобен и не имеет киллер фич из-за которых стоило бы им пользоваться.

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

За это время функционал самого продукта немного поменялся, тоже нужно будет лепить обновления - чем это как-то отличается от допиливания до актуального тулкита?

Тем, что вместо правки функционала, разработчики будут вынуждены тратить время на допиливание до актуального тулкита. Вместо.

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

Почему нельзя на Qt переписать наконец?

Да никто вроде и не запрещает.

Но по сравнению с TortoiseHg это конечно позор. Это моё частное мнение.

Вот как раз TortoiseHg - это позор. Пробовал как-то, слишком много времени уходило даже на элементарные действия. А за line-ending на винде я и вовсе хотел бы пристрелить авторов сего творения.

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

Это костыль. В общем клонить директоию подозреваю оно никогда не осилит

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

нужно будет лепить обновления - чем это как-то отличается от допиливания до актуального тулкита?

Тебе когда-нибудь приходилось перепиливать программы с Qt3 на Qt4? Мне - приходилось. Там даже был конвертер (неплохой, кстати), но всех случаев он не покрывал, к тому же оставлял привязки к модулю Qt3Support, от которого потом всё равно пришлось избавляться.

Рутинная бессмысленная работа, которую можно было потратить на внедрение новых фич. Хотя кутешникам надо отдать должное - при переходе на Qt5 такого трэша и угара уже не было. Даже можно сделать исходники, которые компилятся и там, и здесь.

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

Вспоминается старая шутка; «если вы уверены в том, что мир познаваем, то посмотрите на файл sendmail.cf начиная примерно с пятого экрана». Вот и configspec производит такое же неизгладимое впечатление. А еще можно вспомнить проблему синхронизации репозиториев...

Clearcase хорошо работает в модели RUP, но это ж команду под инструмент надо затачивать...

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

Ой ли. Основная фича ClearCase которой нет и не предвидится ни в одной из других существующих VCS(из популярных во всяком случае), это Dynamic View. В случае работы в крупном проекте с кучей разработчиков - крайне удобная штука.

И что же есть cуть этого самого ДинамикВью?

Просто ви так об энтом пишете, словно бы до git'a каждый пользовался энтой рекламируемой описываемой вами проприетарщиной.

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

Немного опыта, и они пишутся без проблем :)

Ну, знаете… Немного опыта и в, простите, попу консервная банка влезет. Только вот зачем?

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