The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск распределенной системы управления исходными текстами Git 2.23

17.08.2019 03:22

Представлен выпуск распределенной системы управления исходными текстами Git 2.23.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.

По сравнению с прошлым выпуском в новую версию принято 505 изменений, подготовленных при участии 77 разработчиков, из которых 26 впервые приняли участие в разработке. Основные новшества:

  • Представлены экспериментальные команды "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);
  • Добавлены опции "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 в самом начале списка независимо от локали.


  1. Главная ссылка к новости (https://github.blog/2019-08-16...)
  2. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.22
  3. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.21
  4. OpenNews: Фонд Apache перевёл свои Git-репозитории на GitHub
  5. OpenNews: Зафиксирована атака вредоносных шифровальщиков на Git-репозитории (дополнено)
  6. OpenNews: GitHub ввёл в строй реестр пакетов, совместимый с NPM, Docker, Maven, NuGet и RubyGems
Автор новости: имя
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51300-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (38) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Doctor (??), 07:56, 17/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –13 +/
    Свитчинга веток, кстати говоря, довольно нужная вещь.
    Если не про топику, хотелось бы иметь апи по получению инфы по задачам и пулл реквестам, ну тут уже надо к сервисам обращаться, ибо, насколько я знаю, у чистого гита эти полномочия всё
     
     
  • 2.5, Ydro (?), 11:12, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Тот случай, когда ИИ не справилось с грамматикой.
     
  • 2.7, Аноним (7), 15:22, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чувак у тебя каша в голове
     
     
  • 3.8, Петкун (?), 16:40, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А кто такой Заболотный?
     
     
  • 4.25, Линус Торвальдс (?), 09:59, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я
     

  • 1.6, kravich (ok), 15:17, 17/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >"git switch" и "git restore", призванные разделить между собой малосвязанные возможности "git checkout"

    Что делается-то, а...

     
     
  • 2.9, хотел спросить (?), 18:09, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    мало делается.. git давно надо было причесать и унифицировать между платформами

    попробуй сделать реврайт автора без скрипта с гитхаба

     
     
  • 3.13, Crazy Alex (ok), 20:30, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а что там делать? Создал патч, ресетнул, выставил в конфиге правильного автора, наложил дифф, закоммитил. Задача одноразовая, так что логично, что в одно действие не делается. Но заскриптовать при нужде - пять минут.
     
  • 3.14, Аноним (14), 21:11, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > попробуй сделать реврайт автора без скрипта с гитхаба

    Если речь о послеледнем коммите, то commit --amend. Если речь обо всей истории, то filter-tree --env-filter. Зачем какой-то скрипт?

     
     
  • 4.15, хотел спросить (?), 23:02, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> попробуй сделать реврайт автора без скрипта с гитхаба
    > Если речь о послеледнем коммите, то commit --amend. Если речь обо всей
    > истории, то filter-tree --env-filter. Зачем какой-то скрипт?

    как раз filter-tree --env-filter и используется
    но почему нельзя сделать максимально удобным это всё?
    намутили параметров ни разу не user-friendly
    иногда ffmpeg проще, чем в гит

     
     
  • 5.18, Crazy Alex (ok), 00:24, 18/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что экзотических задач - миллион, все удобными не сделаешь. Для экзотики есть базовый инструментарий, который комбинируешь и получаешь то, что надо
     
  • 5.21, Аноним (14), 09:04, 18/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > как раз filter-tree --env-filter и используется
    > но почему нельзя сделать максимально удобным это всё?

    Оно достаточно удобно для такой редко встающей задачи и достаточно гибко, чтобы решать множество других редко встающих задач. И я хоть убей не понимаю, на кой тебе понадобился какой-то скрипт с гитхаба. Ты не в состоянии проверить значение переменной и изменить его?

     
  • 5.26, Аноним (26), 13:05, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > но почему нельзя сделать максимально удобным это всё?

    Потому что нефиг вообще переписывать историю. Это так, если концептуально и глобально. А если локально, то вот тут вам правильно ответили, что есть специфические команды для специфических задач. Другое дело, что и базовые - весьма ... м.... своеобразны.

     
     
  • 6.37, хотел спросить (?), 23:50, 20/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> но почему нельзя сделать максимально удобным это всё?
    > Потому что нефиг вообще переписывать историю. Это так, если концептуально и глобально.
    > А если локально, то вот тут вам правильно ответили, что есть
    > специфические команды для специфических задач. Другое дело, что и базовые -
    > весьма ... м.... своеобразны.

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

     
  • 4.17, Crazy Alex (ok), 00:21, 18/08/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    amend тут не поможет. Точнее, надо ещё --reset-author
     
  • 2.12, Crazy Alex (ok), 20:27, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Концептуально красиво, но на практике - совершенно один хрен. Утешает только то, что это не питонщики, совместимость ломать не станут.
     

  • 1.10, Аноним (10), 18:32, 17/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Git - Самый убогий bloatware интерфейс командной строки.
     
     
  • 2.24, Линус Торвальдс (?), 09:58, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А мне нравится.
     

  • 1.11, Аноним (11), 19:40, 17/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Долой git, даёшь Subversion.
     
     
  • 2.23, Аноним (23), 09:57, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Долой Subversion, даёшь ФинальнаяВерсия_ИсправленияОт311219_исправлено_доработать_ДляВаси_v079_проект.ZIP
     

  • 1.16, Аноним (16), 23:11, 17/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Гит норм. Ни разу не подводил. Правда, пару раз перезатирал историю ребейзом, и

    Но кто никогда не чудил с ребейзом - пусть первый бросит в меня камень

     
     
  • 2.19, Michael Shigorin (ok), 02:58, 18/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://tomayko.com/writings/the-thing-about-git :-)

    Ну и да, git rebase -i -- это такая бензопила, у меня привычка уже на всякий сперва затарить копию репозитория в сторонку, хоть и про git reflog в курсе...

     
     
  • 3.20, имя (?), 03:10, 18/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Подождите, *интерактивный* rebase — бензопила как раз более простая, тупо исполняет инструкции «положить в стопку» и «смешать, но не взбалтывать» как написано. С ним-то вы как умудряетесь довести дело до cp -R?
     
     
  • 4.30, Michael Shigorin (ok), 16:14, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > С ним-то вы как умудряетесь довести дело до cp -R?

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

     
     
  • 5.32, пох. (?), 16:53, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а ведь у hg _этих_ проблем давным-давно нет...

     
     
  • 6.36, хоп (?), 04:34, 20/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    современные погромисты за редким исключением не знают про существование hg
     
  • 3.22, myhand (ok), 09:07, 18/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > https://tomayko.com/writings/the-thing-about-git :-)

    Мда, в гит почитай каждая команда сделана по типу "сделай мне
    зашибись".  Пару раз вляпывался в ситуацию, когда хочется закоммитить
    только часть патча в рабочей копии, а до почитать man git-add
    руки так и не дошли.  

    > git rebase -i -- это такая бензопила, у меня привычка уже на всякий сперва затарить копию репозитория в сторонку

    Что-то вы делаете сильно не так.  --abort никогда не вызывал проблем, если хочется
    "все взад".  Если жалко работы по разрешению конфликтов - есть git-rerere.

     
     
  • 4.29, Michael Shigorin (ok), 16:13, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> git rebase -i -- это такая бензопила, у меня привычка уже на всякий сперва
    >> затарить копию репозитория в сторонку
    > Что-то вы делаете сильно не так.  --abort никогда не вызывал проблем,
    > если хочется "все взад".

    Возможно, десятилетием раньше его ещё просто не было, не помню...

    > Если жалко работы по разрешению конфликтов - есть git-rerere.

    А вот про эту зюку слышал, но так и не читал; спасибо за наводку, порой бы выручило, похоже.

     
  • 3.27, Аноним (27), 15:37, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > у меня привычка уже на всякий сперва затарить копию репозитория в сторонку

    неужели простого
    git tag before_terrible_rebase branch/to/rebase
    не хватает?

    Или эти действия сродни "посмотреть в зеркало", "плюнуть через плечо", "по дереву постучать"?

     
     
  • 4.28, Michael Shigorin (ok), 16:09, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> у меня привычка уже на всякий сперва затарить копию репозитория в сторонку
    > git tag before_terrible_rebase branch/to/rebase

    Это _другое_ действие -- после которого надо ещё этот временный мусор не забыть убрать, иначе затерявшийся тег на чём-то не том может неприятно цапнуть некоторое время спустя, особенно (не) попутешествовав по remote'ам; поэтому в таком плане предпочитаю не теги, а ветки.  Ну и лишний шум в reflog незачем, если буду откатываться -- у меня бывает по нескольку десятков таких налопаченных, но ещё не разобранных и не описанных как положено коммитов порой.

    > Или эти действия сродни

    Скорее про "некоторые ещё не делают бэкапы", если уж очень хочется сострить.

     
     
  • 5.31, Andrey Mitrofanov_N0 (??), 16:26, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> git tag before_terrible_rebase branch/to/rebase
    > Это _другое_ действие -- после которого надо ещё этот временный мусор не
    > забыть убрать, иначе затерявшийся тег на чём-то не том может неприятно
    >> Или эти действия сродни
    > Скорее про "некоторые ещё не делают бэкапы", если уж очень хочется сострить.

    Ну-дк, https://xkcd.com/1597/ как завещал Вкликий Линус [I] . [/I]

     
  • 5.33, Аноним (27), 17:16, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > иначе затерявшийся тег на чём-то не том может неприятно цапнуть некоторое время спустя

    Ты шутишь так чтоль?

    После того как успешно rebase сделал кто тебе запрещает "git tag -d before_terrible_rebase"?
    Тегов боишься - сделай ветку "git branch copy_before_rebase branch/to/rebase".

    Но бэкап перед rebase. Вот уж действительно - "Заставь ****** молиться, он и лоб разобьет".

    Перед "git clone" бэкап ещё не делаешь?

     
     
  • 6.34, Michael Shigorin (ok), 17:18, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ты шутишь так чтоль?

    Дело не в запретах, а в контекстах (можно "щёлкнуть" ими и забыть).  Впрочем, Ваш бисеровалютный лимит на сегодня исчерпан.

     
  • 3.35, KonstantinB (ok), 18:27, 19/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальная бензопила, удобная, если осилить.

    Чтобы не доставать в случае приступа рукозадости из рефлога, сложные ребейзы делаю в отдельной веточке. :)

     
     
  • 4.39, Аноним (39), 10:42, 21/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Точно так же отдельную ветку для ребейза делаю.

    И после ребейза сравниваю старую и ребейзнутую ветки. Должны быть одинаковы, если не выкидывал коммиты.
    git diff старая_ветка..ребейзнутая ветка -- $(git diff --name-only master...старая_ветка)

     
     
  • 5.40, Andrey Mitrofanov_N0 (??), 11:41, 21/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > git diff старая_ветка..ребейзнутая ветка -- $(git diff --name-only master...старая_ветка)

    Ну, ты, б!, давид блеин  и  гари потер.

    git diff спасённая_ветка..

     
     
  • 6.41, Аноним (39), 13:54, 21/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А вот и нет.
    Так Вы захватите файлы которые не меняли в своих ветках.
     

  • 1.38, Аноним (39), 10:37, 21/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > и восстановление файлов в рабочей директории ("git checkout $commit -- $filename") или сразу в staging area

    При checkout и было всегда "сразу в staging area", а уж потом в working directory.
    И вообще checkout это синхронизация рабочей директории с индексом.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру