Git v2.23

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

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

Когда sha256?

Нахоа? Коллизий боишься?

Между разными проектами!

Они ещё не впилили lzma? Что мешает? Или хотя бы zstd.

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

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

Команда 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

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

http://button.dekel.ru/ вам сюда

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

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

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

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

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

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

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

Или хотя бы zstd

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

И переделали бы pull и fetch

Каким образом?

и центральный сервер, чтоб всю историю у себя не хранить, и в svn переименовать...WAIT_OH_SHIT!

Не, пусть остаётся DVCS... И название до двух букв сократить... WAIT... OH, SHIT!..

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

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

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

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

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

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

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

Джва года ждал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плусую. Зачем коммиты хранить дома ?