Представлен (https://lkml.org/lkml/2019/8/16/877) выпуск распределенной системы управления исходными текстами Git 2.23.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.
По сравнению с прошлым выпуском в новую версию принято 505 изменений, подготовленных при участии 77 разработчиков, из которых 26 впервые приняли участие в разработке. Основные новшества (https://github.blog/2019-08-16-highlights-from-git-2-23/):
- Представлены экспериментальные команды "git switch" и "git restore", призванные разделить между собой малосвязанные возможности "git checkout", такие как манипуляция веток (переключение и создание) и восстановление файлов в рабочей директории ("git checkout $commit -- $filename") или сразу в staging area ("--staging", не имеет аналога в "git checkout"). Стоит отметить, что, в отличие от "git checkout", "git restore" удаляет неотслеживаемые файлы из восстанавливаемых директорий ("--no-overlay" по умолчанию).- Добавлена опция "git merge --quit", которая, аналогично "--abort", останавливает процесс слияния веток, но оставляет при этом рабочую директорию нетронутой. Данная опция может оказаться полезной в случае, если некоторые из уже внесённых изменений, внесённых в результате ручного слияния, предпочтительнее оформить в виде отдельного коммита.
- Команды "git clone", "git fetch" и "git push" теперь учитывают наличие коммитов в связанных репозиториях (alternates (https://git-scm.com/docs/gitrepository-layout#Documentation/...));
- Добавлены (https://github.com/git/git/commit/ae3f36dea16e51041c56ba9ed6...) опции "git blame --ignore-rev" и "--ignore-revs-file", позволяющие пропустить коммиты, в которых внесены незначимые правки (например, исправления форматирования);
- Добавлена опция "git cherry-pick --skip" для пропуска конфликтного коммита (запоминаемый аналог последовательности "git reset && git cherry-pick --continue");
- Добавлена настройка status.aheadBehind, фиксирующая опцию "git status --[no-]ahead-behind" на постоянной основе;
- С данного выпуска "git log" по умолчанию учитывает изменения, внесённые mailmap, аналогично тому, как это уже происходит в git shortlog;
- Существенно ускорена операция обновления представленного в 2.18 экспериментального кеша графа коммитов (core.commitGraph). Также ускорен git for-each-ref в случае использования нескольких шаблонов и сокращено количество вызовов auto-gc в "git fetch --multiple";
- "git branch --list" теперь всегда показывает detached HEAD в самом начале списка независимо от локали.
URL: https://github.blog/2019-08-16-highlights-from-git-2-23/
Новость: https://www.opennet.ru/opennews/art.shtml?num=51300
Свитчинга веток, кстати говоря, довольно нужная вещь.
Если не про топику, хотелось бы иметь апи по получению инфы по задачам и пулл реквестам, ну тут уже надо к сервисам обращаться, ибо, насколько я знаю, у чистого гита эти полномочия всё
Тот случай, когда ИИ не справилось с грамматикой.
Чувак у тебя каша в голове
А кто такой Заболотный?
Я
>"git switch" и "git restore", призванные разделить между собой малосвязанные возможности "git checkout"Что делается-то, а...
мало делается.. git давно надо было причесать и унифицировать между платформамипопробуй сделать реврайт автора без скрипта с гитхаба
а что там делать? Создал патч, ресетнул, выставил в конфиге правильного автора, наложил дифф, закоммитил. Задача одноразовая, так что логично, что в одно действие не делается. Но заскриптовать при нужде - пять минут.
> попробуй сделать реврайт автора без скрипта с гитхабаЕсли речь о послеледнем коммите, то commit --amend. Если речь обо всей истории, то filter-tree --env-filter. Зачем какой-то скрипт?
>> попробуй сделать реврайт автора без скрипта с гитхаба
> Если речь о послеледнем коммите, то commit --amend. Если речь обо всей
> истории, то filter-tree --env-filter. Зачем какой-то скрипт?как раз filter-tree --env-filter и используется
но почему нельзя сделать максимально удобным это всё?
намутили параметров ни разу не user-friendly
иногда ffmpeg проще, чем в гит
Потому что экзотических задач - миллион, все удобными не сделаешь. Для экзотики есть базовый инструментарий, который комбинируешь и получаешь то, что надо
> как раз filter-tree --env-filter и используется
> но почему нельзя сделать максимально удобным это всё?Оно достаточно удобно для такой редко встающей задачи и достаточно гибко, чтобы решать множество других редко встающих задач. И я хоть убей не понимаю, на кой тебе понадобился какой-то скрипт с гитхаба. Ты не в состоянии проверить значение переменной и изменить его?
> но почему нельзя сделать максимально удобным это всё?Потому что нефиг вообще переписывать историю. Это так, если концептуально и глобально. А если локально, то вот тут вам правильно ответили, что есть специфические команды для специфических задач. Другое дело, что и базовые - весьма ... м.... своеобразны.
>> но почему нельзя сделать максимально удобным это всё?
> Потому что нефиг вообще переписывать историю. Это так, если концептуально и глобально.
> А если локально, то вот тут вам правильно ответили, что есть
> специфические команды для специфических задач. Другое дело, что и базовые -
> весьма ... м.... своеобразны.ну да давайте расскажите нам что нужно делать, а мы скажем вам куда вам идти
amend тут не поможет. Точнее, надо ещё --reset-author
Концептуально красиво, но на практике - совершенно один хрен. Утешает только то, что это не питонщики, совместимость ломать не станут.
Git - Самый убогий bloatware интерфейс командной строки.
А мне нравится.
Долой git, даёшь Subversion.
Долой Subversion, даёшь ФинальнаяВерсия_ИсправленияОт311219_исправлено_доработать_ДляВаси_v079_проект.ZIP
Гит норм. Ни разу не подводил. Правда, пару раз перезатирал историю ребейзом, иНо кто никогда не чудил с ребейзом - пусть первый бросит в меня камень
https://tomayko.com/writings/the-thing-about-git :-)Ну и да, git rebase -i -- это такая бензопила, у меня привычка уже на всякий сперва затарить копию репозитория в сторонку, хоть и про git reflog в курсе...
Подождите, *интерактивный* rebase — бензопила как раз более простая, тупо исполняет инструкции «положить в стопку» и «смешать, но не взбалтывать» как написано. С ним-то вы как умудряетесь довести дело до cp -R?
> С ним-то вы как умудряетесь довести дело до cp -R?Например, перестраивая порядок конфликтующих патчей и выравнивая к тому, как оно должно было быть. Когда шло несколько параллельных изменений (или разработка и срочные мелочи там же), но в итоге лучше не мегапатч, а логическая цепочка преобразований.
а ведь у hg _этих_ проблем давным-давно нет...
современные погромисты за редким исключением не знают про существование hg
> https://tomayko.com/writings/the-thing-about-git :-)Мда, в гит почитай каждая команда сделана по типу "сделай мне
зашибись". Пару раз вляпывался в ситуацию, когда хочется закоммитить
только часть патча в рабочей копии, а до почитать man git-add
руки так и не дошли.> git rebase -i -- это такая бензопила, у меня привычка уже на всякий сперва затарить копию репозитория в сторонку
Что-то вы делаете сильно не так. --abort никогда не вызывал проблем, если хочется
"все взад". Если жалко работы по разрешению конфликтов - есть git-rerere.
>> git rebase -i -- это такая бензопила, у меня привычка уже на всякий сперва
>> затарить копию репозитория в сторонку
> Что-то вы делаете сильно не так. --abort никогда не вызывал проблем,
> если хочется "все взад".Возможно, десятилетием раньше его ещё просто не было, не помню...
> Если жалко работы по разрешению конфликтов - есть git-rerere.
А вот про эту зюку слышал, но так и не читал; спасибо за наводку, порой бы выручило, похоже.
> у меня привычка уже на всякий сперва затарить копию репозитория в сторонкунеужели простого
git tag before_terrible_rebase branch/to/rebase
не хватает?Или эти действия сродни "посмотреть в зеркало", "плюнуть через плечо", "по дереву постучать"?
>> у меня привычка уже на всякий сперва затарить копию репозитория в сторонку
> git tag before_terrible_rebase branch/to/rebaseЭто _другое_ действие -- после которого надо ещё этот временный мусор не забыть убрать, иначе затерявшийся тег на чём-то не том может неприятно цапнуть некоторое время спустя, особенно (не) попутешествовав по remote'ам; поэтому в таком плане предпочитаю не теги, а ветки. Ну и лишний шум в reflog незачем, если буду откатываться -- у меня бывает по нескольку десятков таких налопаченных, но ещё не разобранных и не описанных как положено коммитов порой.
> Или эти действия сродни
Скорее про "некоторые ещё не делают бэкапы", если уж очень хочется сострить.
>> git tag before_terrible_rebase branch/to/rebase
> Это _другое_ действие -- после которого надо ещё этот временный мусор не
> забыть убрать, иначе затерявшийся тег на чём-то не том может неприятно
>> Или эти действия сродни
> Скорее про "некоторые ещё не делают бэкапы", если уж очень хочется сострить.Ну-дк, https://xkcd.com/1597/ как завещал Вкликий Линус .
> иначе затерявшийся тег на чём-то не том может неприятно цапнуть некоторое время спустяТы шутишь так чтоль?
После того как успешно rebase сделал кто тебе запрещает "git tag -d before_terrible_rebase"?
Тегов боишься - сделай ветку "git branch copy_before_rebase branch/to/rebase".Но бэкап перед rebase. Вот уж действительно - "Заставь ****** молиться, он и лоб разобьет".
Перед "git clone" бэкап ещё не делаешь?
> Ты шутишь так чтоль?Дело не в запретах, а в контекстах (можно "щёлкнуть" ими и забыть). Впрочем, Ваш бисеровалютный лимит на сегодня исчерпан.
Нормальная бензопила, удобная, если осилить.Чтобы не доставать в случае приступа рукозадости из рефлога, сложные ребейзы делаю в отдельной веточке. :)
Точно так же отдельную ветку для ребейза делаю.И после ребейза сравниваю старую и ребейзнутую ветки. Должны быть одинаковы, если не выкидывал коммиты.
git diff старая_ветка..ребейзнутая ветка -- $(git diff --name-only master...старая_ветка)
> git diff старая_ветка..ребейзнутая ветка -- $(git diff --name-only master...старая_ветка)Ну, ты, б!, давид блеин и гари потер.
git diff спасённая_ветка..
А вот и нет.
Так Вы захватите файлы которые не меняли в своих ветках.
> и восстановление файлов в рабочей директории ("git checkout $commit -- $filename") или сразу в staging areaПри checkout и было всегда "сразу в staging area", а уж потом в working directory.
И вообще checkout это синхронизация рабочей директории с индексом.