LINUX.ORG.RU

Pijul 0.3

 , , ,


5

4

Состоялся первый публичный релиз системы управления версиями Pijul 0.3, написанной на языке программирования Rust. Pijul объединяет в себе производительность git и простоту использования darcs. Основанная на модели теории патчей, система Pijul направлена на то, чтобы сделать операции слияния и забора определенных коммитов (cherry-pick) более интуитивным.

Pijul можно установить при помощи Cargo (пакетного менеджера для Rust): команда cargo install pijul соберёт самую последнюю версию. Минимальная для сборки версия Rust — 1.15.1.

Примеры использования:

$ mkdir my_project
$ cd my_project
$ pijul init # создание нового пустого репозитория
$ echo " [ ] save the world" > todo.md # редактируем файл
$ pijul add todo.md # добавить todo.md: pijul начнёт отслеживать
                    # изменения в этом файле
$ pijul record # равнозначно 'git commit -p'
added file /home/florent/code/pijul/pijul/pijul/tuto/todo.md
Shall I record this change? [ynkad] y
+  [ ] save the world
Shall I record this change? [ynkad] y
What is your name <and email address>? Jean Doe <jean@example.org>
What is the name of this patch? Lest I forget
Recorded patch AeNEKi1-S60Pe_Hy__lbsyyKIrnkFvDBC-AOG4uUf0KxRG6v2pqwv…

Пример создания клона и внесения изменений; на этот раз команда record используется с ключом -a для сохранения всех изменений в отслеживаемых файлах. pijul record -m <сообщение> добавляет сопутствующее сообщение без необходимости открывания редактора, --author позволяет указать авторство, только для этого случая.

$ cd ..
$ pijul clone my_project clone_of_my_project
$ cd clone_of_my_project
$ echo " [ ] save the world, starting with the koalas" > todo.md
$ pijul record -am "Think of the koalas" --author koala_lover@example.au
Recorded patch ATqiYHQE528y0irRT4Oh0HEGbsR9e8J-7VMqUljUvsmduIcBU1YGdN_Abg…

Возвращаемся в исходный репозиторий и мерждим изменения:

$ cd ../my_project
$ pijul pull ../clone_of_my_project
Hash: ATqiYHQE528y0irRT4Oh0HEGbsR9e8J-7VMqUljUvsmduIcBU1YGdN_AbgpWZ7eaj-1q3dOA2OU5YYA1t1DY_T8
Authors: ["koala_lover@example.au"]
Timestamp 2017-03-16 16:50:49.059851279 UTC
  * Think of the koalas
Shall I pull this patch? [ynkad] y
 
$ cat todo.md 
 [ ] save the world, starting with the koalas

Pijul — пока очень молодой проект: разработчики сами только начали его использовать для разработки самого проекта Pijul.

Проект назван в честь ани — вида южноамериканских птиц, которые часто живут группами по четыре-пять особей. Они защищают свою территорию вместе, откладывают яйца в одно общее гнездо. Все члены группы насиживают их и заботятся о молодняке, даже молодые помогают заботиться о птенцах.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 5)

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

Во-вторых, какое тебе дело диффы у него под капотом или снимки?

Спроси об этом авторов pro git, которые первое что пишут про git — это то, как он хранит данные.

Работа с VCS не зависит от того как у неё кишки устроены.

Очевидно, что это не так.

Я долгое время был уверен что git хранит как раз diff'ы.

Что подтверждает мои слова про контринтуитивное, наркоманское устройство git.

utf8nowhere ★★★
()

релиз системы управления версиями Pijul 0.3

Сходу ничего не понял, но судя по всему - Агонь!

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

факт что в git можно достать ЧАСТИЧНЫЙ diff чтобы его закоммитить, не тронув другие изменения в файле(хотя вот эта фича - воистину наркоманская!)

Наркоманская? Да без этого невозможно работать! git add -p и git add -e - без них получается свалка в истории вместо коммитов. У mercurial есть аналогичная функциональность - hg crecord.

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

Яйцеголовые жертвы высшего образования. Сделали клон популярного инструмента

Ты малолетний недоучка. Теория патчей (первый раз реализованная в DARCS) старше DVCS, построенных на криптохешах.

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

А Mercurial просто работает, я его вообще не замечаю обычно

а, так для личного использования и rcs/cvs, прости господи, подойдет. а в команде с этим hg такие головняки, что переход на git у нас был воспринят с небывалым энтузиазмом. историю он (hq) пишет исправно, но понять по ней, что, на самом деле делалось, бывает очень сложно даже автору этих самых изненений. показателно, что для работы над задачей, со избежание «шума», предлагалось клонировать репу и работать там до получения окончательного результата и уже его вливать в общее русло. правда не обьяснялось, как можно отличить окончательный результат, от промежуточного в условиях, когда требования меняются налету.

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

Это поклёп, - с историей изменений mercurial работает лучше git. Вот со стиранием ревизий на удалённом репозитории у mercurial не очень.

Sorcerer ★★★★★
()

бороздчТатоклювого ани

Раза с пятого прочитать осилил. Ну нельзя же так!

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

с историей изменений mercurial работает лучше git

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

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

в git я всегда могу rebase сделать и объединить то, что по сути является одним целым

В hg - тоже. Ты просто не умеешь, но это не проблема hg.

в hg если что-то попало в историю оно там навсегда

Какое откровенное признание в невежестве.

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

Откройте для себя hg histedit. Как вы не осилили открыть это для себя всей командой, пока работали с mercurial?

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

А, его уже довели до ума? Это хорошо, а то пару лет назад оно сырое и экспериментальное было.

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

сначала модифицировал файл A, а потом B, я не могу вытащить изменения для файла B, не трогая файл A

Чем тебя не устраивает checkout --patch

no-such-file ★★★★★
()
Ответ на: комментарий от Sorcerer

Histedit - это какое-то расширение которое было срисовано с git rebase, но не с чистого ребейза, а с --interactive. Это не то, иногда комиты ребейзятся просто так, без --interactive. git pull --rebase например.

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

Я юзаю. По-моему, лучшая из DVCS (из известных мне на данный момент). Но только для себя (в командах приходится юзать всякое: git, svn, cvs).

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

А так только SVN, только хардкор! Ибо он прост как пробка и без лишних свистоперделок.

А RCS ещё проще.

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

В hg - тоже. Ты просто не умеешь, но это не проблема hg

вы просто не понимаете или не хотите видеть огромной разницы между историей изменений отдельных файлов, поддерживаемой hg, и историей, которую программист считает нужной сохранять. а все эти жалкие потуги компенсировать недостатки hg при помощи плагинов, которые не могут, в принципе, изменить примитивность hg. изобразите-ка мне аналог git rebase --onto, который я часто использую... ах да, брэнчи в hg прибиваются гвоздями.

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

hg pull && hg rebase

разница между git rebase и hg rebase как между, скажем...

git: хочу как у мадонны было на прошлом грэми только с зелеными пуговицами

hg: видели мадонну на прошлом грэми? надо так же и меня не ипет, как вы это сделаете. а почему пуговицы фиолетовые?!!! мы же еще прошлым летом договорились, что они должны быть зелеными

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

Прямо целым отделом неосиляторов, которых заставляют работать по субботам?

не, по субботам мы развлекаемся. иногда кто-нибудь делится хохмами о вас

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

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

А ты, конечно, этой разницы не объяснишь.

изобразите-ка мне аналог git rebase --onto

hg help rebase, чо

.. ах да, брэнчи в hg прибиваются гвоздями.

Среди многих видов бранчей в hg есть ровно такие жн, как в git.

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

hg pull && hg rebase

я не думаю, что это тоже самое, что git pull --rebase. хотя бы потому что hg pull и git pull делают разные вещи.

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

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

но в общем я рад, что в меркуриале есть ребейзы и всё такое

меркуриал потихоньку приближается к юзабельному виду

Если что, rebase в Mercurial есть уже лет 7-8. А mq - и все 12.

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

Да божья роса это всё. Всем известно, что развивается только и исключительно софт, за которым специально следишь.

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

Во-вторых, какое тебе дело диффы у него под капотом или снимки?

Спроси об этом авторов pro git

т.е. ты сам не в курсе?

Работа с VCS не зависит от того как у неё кишки устроены.

Очевидно, что это не так.

От того, как устроены кишки зависит только скорость выполнения тех или иных операций. Авторы pro git упоминают об этом потому, что делают упор на скорость работы с ветками.

Ты, кстати, в курсе, что SVN давным давно отказались от чистых diff'ов и каждый 10-й коммит хранят снапшотом именно ради скорости?

Я долгое время был уверен что git хранит как раз diff'ы.

Что подтверждает мои слова про контринтуитивное, наркоманское устройство git.

Роторно-поршневой двигатель Ванкеля тоже некоторые считают наркоманией, но кому какое дело, если автомобиль едет?

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

а, так для личного использования ...

Ну так львиная доля всех VCS и применяется «в одно рыло» :)

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

Вот со стиранием ревизий на удалённом репозитории у mercurial не очень.

Хех. На удалённом. Я в Git локально уже столько раз терял наработки, что зарёкся хоть что-то его автоматике доверять :D

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

Я не говорю что это фича плохая. Это годная наркомания! Но по первачу у меня мозг взорвался, когда я об этом читал и пробовал применить.

Pinkbyte ★★★★★
()

Pijul uses only patches, which are atomic components of team work. In Pijul, a branch is exactly a set of patches.

Не взлетит. Тот же git стал популярным из-за того, что изначально отказался от этой идиотской идеи.

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

этот ваш рефлог за полдня загаживается однотипными записями до неюзабельного состояния. и это не говоря про gc --auto.

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

этот ваш рефлог за полдня загаживается однотипными записями до неюзабельного состояния

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

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

git стал популярным из-за того, что изначально отказался от этой идиотской идеи.

Git ни от чего он не отказывался - Линусу было нужно хоть что-нибудь, но быстро, поэтому он наговнокодил простейшую CAM. А дальше на имя Линуса подтянулись кодеры, которые не дали поделке помереть.

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

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

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

работу надо работать, а не коммитить по одной строк

Ты просто завидуешь, что не можешь коммитить каждую строку.

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

Линус накодил то, чем было удобно пользоваться

Вот теперь я точно знаю, что лет тебе немного, ты не видел Git образца 2005 года и не знаешь, кто и как его доводил.

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

Пришло время пояснить суть. Есть две модели системы контроля версий: на основе патчей и на основе снимков. Первая — наиболее естественная, но исторически крайне медленная, к примеру, простой мердж в darcs может длиться неделями (экспоненциальное время, ага). Вторая быстра, но любое неосторожное движение приводит к извращениям с ручным слиянием (кто пробовал всерьёз править чужие PR'ы, тот поймёт).
Так вот, создателям pijul'я удалось решить проблему с производительностью, из-за который системы контроля версий с моделью патчей было невозможно использовать. И это круто.
А гит стал популярным потому, что распределённый, быстрый, и Линус. Да и из альтернатив были одни лишь меркуриал и базаар.

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

вообще-то переключение веток тоже добавляет записей в рефлог. вы с ним работали вообще?

если что-то потерялось, то это обычно сразу становится понятно

часто, но не всегда. К примеру, при переписывании одной и той же ветки в разных репозиториях и последующем force push (in before: да, так делать не надо, т.к. отстрелить ногу очень легко, но средств предотвратить это git не имеет)

littlechris ★★★
()
Последнее исправление: littlechris (всего исправлений: 1)

производительность git
простоту использования darcs

Ну хоть не производительность svn и простоту использования Fossil и на том спасибо.

Gentooshnik ★★★★★
()

О, идейный наследник darcs, жаль правда что с окамля на раст перешли. Успехов проекту, а то по работе приходится со сраным git возиться. Если б не magit - вообще задница была бы.

zabbal ★★★★★
()

Кстати о птичках

Проект назван в честь бороздчтатоклювого ани

https://ru.wikipedia.org/wiki/Бороздчатоклювый_ани

И где там пичули ваши? Вообще нет такого слова. Я даже english нажал, и всё равно нету. И по латински тоже по другому называется.

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