Автор Гілка: jj — нова система контролю версій  (Прочитано 431 раз)

Відсутній Володимир Лісівка

  • Адміністратор ЩОДО
  • Видавець
  • *****
  • дописів: 3888
  • Карма: +13/-0
  • Програміст
jj (jujutsu) — це система контролю версій, яка намагається взяти найкраще з git, mercurial, і darcs, а також додає нові можливості, такі як записування всіх дій з репозиторієм та робочою копією, зберігання конфліктів. Як сховище використовуються сервери Git, що дозволяє використовувати вже наявну інфраструктуру.

Проєкт: https://github.com/jj-vcs/jj
[Fedora Linux]

Відсутній yvs115

  • Кореспондент
  • ***
  • дописів: 122
  • Карма: +3/-0
Re: jj — нова система контролю версій
« Відповідей #1 : 2025-06-23 17:50:59 »
Чесно кажучи після появи git - питання versioning софта практично закрилося, і що такого особливого може бути запропоновано в рамках version control щоб перейти з git - уявити зараз важко. В деяких репо у мене ще досі залишались нп svn, але то тільки тому що лінь переносити те чим дуже рідко користуєшся.
З різних scm єдине що колись привертало уваги - це додатковий функціонал - як нп fossil-scm (з екстра було щось вбудоване wiki, site, ...) https://fossil-scm.org/home/doc/tip/www/fossil-v-git.wiki. І який так і не спробував ніде.
Тобто навіть заради додаткового функціоналу - думаю що рідко хто  щось використовує окрім git. Якщо щось реально використовується - то було б цікаво - що там є.
« Змінено: 2025-06-23 18:08:35 від yvs115 »

Відсутній Володимир Лісівка

  • Адміністратор ЩОДО
  • Видавець
  • *****
  • дописів: 3888
  • Карма: +13/-0
  • Програміст
Re: jj — нова система контролю версій
« Відповідей #2 : 2025-06-23 20:17:26 »
Я працював з сирими латками, RCS, CVS, SS, SVN, Git. Всі вони сумісні між собою, тобто (лінійну) історію якоїсь гілки репозиторію можна перетворити в набір латок і навпаки. Але Git найзручніший з них. З іншого боку, Git дуже незручний коли щось пішло не так, і потрібно розібратися чому так сталося і як виправити проблему, не втрачаючи новостворений код. А в GIT досить легко наступити на граблі. Наприклад, якщо під час коміту була допущена помилка, то можна змінити історію через --amend і пушнути її на сервер, але тоді якщо колеги чи CI встигли стягнути помилкову версію коміта, то у них виникнуть конфлікти при наступній синхронізації через різну історію і потрібне буде ручне втручання. А якщо колеги зробили rebase поверх помилкового коміта чи зробили нову гілку, то вони можуть сильно образитись і навіть дати по сраці, бо вони можуть втратити свої зміни.
[Fedora Linux]