LINUX.ORG.RU

Git v2.23

 


2

3

Вышла новая версия системы контроля версий. Она содержит 505 изменений относительно предыдущей – 2.22.

Добавлены две новые экспериментальные команды для разделения возможностей переусложнённой команды git checkout:

  • git switch - переключение веток
  • git restore - восстановление файлов.

Ещё изменения:

  • Обновлены вспомогательные команды git rebase для удаления неиспользуемого кода.
  • Команда git update-server-info не переписывает файл, если его содержимое осталось неизменным.
  • Команда git mergetool и ее тесты теперь порождают меньшее количество подпроцессов.
  • Команда git for-each-ref при запуске без аргументов предоставляет список всех ссылок вместе с коммитами, на которые они указывают.

А также много других улучшений и изменений.

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

anonymous

Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 2)

действия, выполняемые командой git checkout разделены между двумя командами: git switch и git restore

Чёго, блин? Верните всё обратно. Лучше вообще всё заменить одной `git doit` и всё.

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

Они ещё не впилили lzma? Что мешает?

Тебя ждут. Или твоих донатов. Или сразу коммитов.

Alve ★★★★★
()

Команда git for-each-ref запуске без аргументов предоставляет список всех ссылок вместе с коммитами, на которые они указывают.

А что, было как-то по-другому?

$ git --version
git version 2.22.1

$ git for-each-ref
46b3fad743b4d9ee19f09272e09b6329c07b74be commit refs/heads/master
46b3fad743b4d9ee19f09272e09b6329c07b74be commit refs/remotes/origin/HEAD
e60cdaa01001d4b04e0c36ee31d41a21c8bdc64c commit refs/remotes/origin/cmake
46b3fad743b4d9ee19f09272e09b6329c07b74be commit refs/remotes/origin/master

В анонсе тоже ничего про это.

intelfx ★★★★★
()

Добавлены две новые экспериментальные команды для разделения возможностей переусложнённой команды git checkout:

Вот и правильно.

WatchCat ★★★★★
()

Добавлены две новые экспериментальные команды для разделения возможностей переусложнённой команды git checkout

Ещё бы reset так раскурочили. И переделали бы pull и fetch.

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

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

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

Они ещё не впилили lzma?

Чтобы git log еще медленнее работал в больших репозиториях?

Или хотя бы zstd

Вот это другое дело

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

Зачем хранить у себя всю историю? Ты до сих пор не умеешь скачивать нужное количество изменений и определённые ветки?

а, это был сарказм

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

человекочитаемую нумерацию коммитов

Например? В hg нумерация локальная и при ссылке на коммит в сообщении другому человеку всё равно придётся давать хэш

Но раз уж зашла тема о нём, может мне кто пояснить по имущества создания в нём локального клона репы для внесения правок перед созданием ветки в нём же? Я не понял этот usecase в их guide

https://www.mercurial-scm.org/guide#separate_features

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

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

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

может мне кто пояснить по имущества создания в нём локального клона репы для внесения правок перед созданием ветки в нём же?

По-моему, всё очевидно: чтобы внутри одного репозитория не переключаться между ветками с незакомиченными изменениями, имея неосторожность случайно потерять код. Для этих же целей есть hg shelve, который, якобы, как git stash, но в отличие от последнего имеет понятную и прозрачную логику.

Что касается нумерации, то обычно так или иначе имеется «центральный» репозитория, к которому и можно и нужно делать отсылку.

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

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

«центральный» репозитория, к которому и можно и нужно делать отсылку.

Это если там вдруг не разрешено внесение изменений, так как возможность делать rebase в hg тоже есть, посредством расширения, хоть и отключена по умолчанию. Но обычно при использовании hg, насколько я понял, к этому стараются не прибегать и зависит от договорённости в группе.

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

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

Это надо постараться потерять незакоммиченные изменения при переключении ветки, т.к., например, в git они, судя по документации, никуда из рабочего дерева не исчезают. Если reset (--hard) не делать после переключения.

Я как-то намудрил ночью и сбросил 7 коммитов :) Хорошо, что есть reflog.

Но с hg нужно тоже ознакомится получше,а не только через черепаху-воркбенч.

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

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

не обязательно. Например, ты работаешь над какой-то фичей, и в самом разгаре приходит запрос на исправления бага в другой ветке. Коммитить неохота, поскольку всё сыро и не отлажено. Вот тут на помощь и приходит hg shelve, но в неумелых руках он может превратиться в инструмент для отпиливания ноги (хоть это надо и постараться :). Иметь совсем отдельный репозиторий для каждой фичи — панацея от подобных случаев для новичков (тем более, что раньше shelve был сторонним расширением).

Это если там вдруг не разрешено внесение изменений, так как возможность делать rebase в hg тоже есть

Я сторонник подхода «неизменяемой» истории, так что велкам ребэйзить в локальном репозитории, но в центральном лучше до такого не доводить :) Ну и никто не отменял хэши для ссылки на коммиты. Просто, например, делать bisect по истории проще с человекочитаемыми номерами, проверено на себе.

Это надо постараться потерять незакоммиченные изменения при переключении ветки, т.к., например, в git они, судя по документации, никуда из рабочего дерева не исчезают. Если reset (--hard) не делать после переключения.

Это легко делается и в hg, и в git. Просто в hg сообщения и команды более внятные/вменяемые. Данная новость, в общем-то, об этом :)

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

Вот проблема со скачиванием истории частично в mercurial меня огорчила. hg clone --rev коммит , к сожалению, качает от начала истории до указанного коммита :(

Пару раз мне нужно было сделать rebase и/или добавить мелкое исправление в репе gentoo (через git), под рукой был только смартфон, на который клонировать всю репу и историю очень не хотелось (очень большой расход трафика). Но зато получилось скопировать отдельные (нужные) директории и последние несколько коммитов истории.

Против hg ничего против не имею и локально его использовал для своих целей.

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