Pijul 0.11

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

ЛОР большой, всех дурачков в лицо я знать не могу, особенно среди анонимусов. Приходится перестраховываться.

Боже мой что я прочитал. Они стреляют себе в ногу потом орут что «мама, у меня дыра в ноге». Все примеры содержат явный выстрел, хотя язык даёт возможность не стрелять. Нет, откопаем опасную функцию которую разрабы раста с бодуна решили сделать не unsafe, будем с ней бегать голыми по город.

Пора взломать раст, поделю на ноль что ли

> git add -p

Окей. Похоже, не самая известная команда.

«я плакалъ» (ц)

Ты утверждаешь, что осиливание Хаскеля и Си требует одинаковых усилий.

Ну это конечно наглая ложь, ведь Хаскель требует куда меньше усилий, чтобы научиться писать на нём что-то работающее.

Что за теория патчей?

Ты ответил не туда.

Проблемы с этим?

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

Затем, что они решают обсуждаемую задачу.

— Задача: <...> Как ты это будешь решать без индекса?
— Средствам работы с очередями патчей уже как минимум 17 лет - quilt, mq, stgit.
— Как средства работы с очередями патчей помогут [решить задачу]?
— Никак, это надо делать вручную.

Действительно.

ХЗ кто и зачем это написал, но record extension уже давно является стандартной частью Mercurial.

Во-первых, я скорее поверю оф. вики проекта, чем тебе. Во-вторых, эти два утверждения друг другу не противоречат. Record extension мог сначала стать стандартной частью Mercurial, а потом быть задепрекейченным (насколько я понимаю, так и произошло).

Ненужная вещь. То, что ее смогли приспособить для решения нужной задачи, не делает ее саму нужной.

Манёвр не засчитан (см. ниже).

tailgunner

Какие у тебя претензии к индексу тогда?

Ненужная вещь. То, что ее смогли приспособить для решения нужной задачи, не делает ее саму нужной.

Также и с гитом. Сам по себе индекс не нужен. Коммитить отдельные куски файла можно и без него: hg commit -i так и делает — просто спрашивает, какие куски файла я хочу скоммитить. Но да, мы в гите придумали бесполезную штуку, а потом с её помощью героически решили проблему, которую намного легче и понятнее было решить без неё.

Коммитить отдельные куски файла нельзя без индекса. Индекс, по определению — это хранилище объектов, которые войдут в следующий коммит. Чтобы закоммитить «отдельный кусок файла» (расшифрую: часть изменений файла), необходимо сначала создать частичный патч, потом применить его к исходной версии объекта, потом закоммитить частично изменённый объект. На втором шаге у нас в том или ином виде получается индекс.

Возможно, в Mercurial этот индекс хранится только в памяти процесса hg commit --interactive и без вариантов отбрасывается по его завершении, но он там есть. Разница только в том, что в Mercurial он без вариантов эфемерный, а в Git он персистентный и хранится на диске.

Выходит, претензия к Git в том, что он предоставляет больше возможностей, чем нужно tailgunner'у? Так себе претензия.

Ты утверждаешь, что осиливание Хаскеля и Си требует одинаковых усилий.

Ну это конечно наглая ложь, ведь Хаскель требует куда меньше усилий, чтобы научиться писать на нём что-то работающее.

Чтобы опровергнуть ложь, ты прибег к еще большей?) Единственное, что на хаскеле требует _куда_ меньших усилий, это саморекурсивные типы данных. И то благодаря «жирному» рантайму.

Как ни странно, на одиннадцатой странице треда про Rust и VCS по-прежнему обсуждаются Rust и VCS!

Ага, только обсуждают почему-то гит, а не сабжевый выхухоль.

Выходит, претензия к Git в том, что он предоставляет больше возможностей, чем нужно tailgunner'у?

Я по наивности считал, что индекс — одна из киллерфич гита, а оно оказывается нинужна. Сам тылгунер с лора сказал! Всё, срочно выбрасываем запутанный гит, будем внедрять CVS.

Дался вам этот сборщик мусора. Почему-то включать в программу на си баш вместе с перлом или луа зазорным не считается, а вот взять и написать на языке со сборкой мусора - считается.

Как раз таки иногда очень нужно отсутствие GC, например, для бесшовной интеграции с питоном, математикой и матлабом. Здесь раст должен быть очень хорош, в отличие от того же хаскеля.

Скажем так, программные системы с GC стремятся к самодостаточности, оборотной стороной чего является изолированность от других программных систем. Яркий тому пример - жаба. Сколько же повторно было изобретено кода, лишь бы получить заветную пьюрэ-жаба-хандрид-пёрснт! А жабий JNI - еще тот подарок!

Хаскель требует куда меньше усилий, чтобы научиться писать на нём что-то работающее.

Что-то работающее, а именно Hello World написать одинаково легко. Что-то полезное на Haskell написать трудно. До сих пор никому это не удалось.

Живой фанбой Хаскеля, какая милота.

Ты ответил не туда.

Это старый глюк ЛОР.

Действительно.

У тебя проблемы с пониманием текста.

Коммитить отдельные куски файла нельзя без индекса.

Можно.

Возможно, в Mercurial этот индекс хранится только в памяти процесса hg commit --interactive и без вариантов отбрасывается по его завершении, но он там есть.

Такой «индекс» есть и в Git. Т.е. в твоих терминах в Git два индекса (анонимус считает, что даже три).

Разница только в том, что в Mercurial он без вариантов эфемерный, а в Git он персистентный и хранится на диске.

Разница в том, что mq не вытаскивает ненужные детали в UI.

Выходит, претензия к Git в том, что он предоставляет больше возможностей, чем нужно tailgunner'у? Так себе претензия.

Если ты не понял ни меня, ни анонимуса Pijul 0.11 (комментарий), я тебе не доктор.

Возможно, в Mercurial этот индекс хранится только в памяти процесса hg commit --interactive и без вариантов отбрасывается по его завершении, но он там есть. Разница только в том, что в Mercurial он без вариантов эфемерный, а в Git он персистентный и хранится на диске.

Но что в таком случае считать индексом?

Индекс, по определению — это хранилище объектов, которые войдут в следующий коммит.

Странное определение... Возьмём гипотетическую VCS, которая коммитит код по кускам как-то так:

commit = []
for file in files_to_commit:
    for chunk in file.chunks:
        if user_wants_this_chunk(file, chunk):
            commit.add(file, chunk)

repo.add(commit)

Что в этом случае считать индексом? Переменную commit? Но это же просто формирование запроса в переменной. Это просто переменная!

Такая переменная-«индекс» есть в любой программе, которая отправляет SQL-запрос в базу данных. В printf есть такой «индекс» — промежуточная строка, в которую складываются символы перед выводом. Да и вообще, любая переменная в мире — это промежуточное хранилище какого-то результата. Не называть же все переменные «индексами»?

Но давайте попридираемся к словам...

Индекс, по определению — это хранилище объектов, которые войдут в следующий коммит.

То есть индекс — это не любая переменная, а только та, в которой хранится промежуточный результат перед коммитом. Ну ок, тогда в меркуриале такая переменная есть. А в гите таких хранилища минимум три. Одно в переменной в git add -p, другое на диске, третье в переменной в git commit.

Выходит, претензия к Git в том, что он предоставляет больше возможностей, чем нужно tailgunner'у?

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

В примере выше: в гите для коммита файлов по кускам используется как минимум три «индекса», а можно было обойтись одним — переменной в памяти.

PS: сущность «ненужная», если без неё задача решается так же или проще.

Но нормальные GC уже давно не тормозят, если памяти с избытком. В DCVS для чего отказываться от GC, сколько же оно жрёт?

Вот! Как раз таки GC тормозят, когда памяти с избытком. Парадокс. Хотя все ожидаемо. Видимо растет сложность алгоритмов.

Так, надо прояснить. Параллельный сборщик с поколениями использует достаточно много «лишней» кучи, именно поэтому я говорил о «не тормозят, если памяти с избытком».

Далее. Пропускная способность таких сборщиков достаточно большая. Это означает, что они слабо тормозят программу в среднем. То есть в процентах от производительности. Это не означает, что в интерактивных приложениях не будет пауз и подвисаний. Это влияет на FPS в играх, влияет на плавность курсора мыши в IDE. Но очевидно, что в работе консольного CVS эти микро-паузы заметить невозможно. А скорость работы такого CVS будет почти такая же, как у CVS без GC (то есть какой объём работы он способен выполнить за единицу времени).

О каких конкретно тормозах говорил ты?

Во-первых, другие алгоритмы;

Подробнее можешь?

во-вторых, в Rust нет ленивости, за счет которой потребление памяти Darcs иногда уходило в небеса (подробностей не знаю, но так говорил разработчик).

Проблема излишнего потребления памяти при ленивости существует. К счастью, она давно решена в Haskell с помощью аннотаций строгости.

И в Rust афинные типы.

Спасибо за буквоедство, поправка принята

Во-первых, другие алгоритмы;

Подробнее можешь?

https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users

Ссылка на мозголомную статью есть в начале топика.

Но что в таком случае считать индексом?

Индекс в гите - это как транзакция. Все и все патчи (кусочки патчей) согласованы. Если был глобальный рефакторинг кода, то ты не вытащишь отдельные несогласованные патчи и не сломаешь свой бесценный проект.

Продолжу. А вот как работает так называемая «теория патчей» с согласованными патчами? Это вот очень интересный вопрос. Вроде бы, никак. То есть это очередная игрушка для теоретиков.

Ага, только обсуждают почему-то гит, а не сабжевый выхухоль.

Так там нечего пока обсуждать.

Но что в таком случае считать индексом?

Индекс, по определению — это хранилище объектов, которые войдут в следующий коммит.

Странное определение...

Странное, но корректное.

Что в этом случае считать индексом? Переменную commit?

Да.

Но это же просто формирование запроса в переменной. Это просто переменная!

Всё, что угодно — это «просто переменная», или «просто файл», или «просто ещё что-нибудь». Ты демагогию не разводи.

Не называть же все переменные «индексами»?

Нет, не называть, потому что не любая переменная является хранилищем объектов, которые войдут в следующий коммит. Ну да ты и сам это понял (удивительно!).

А в гите таких хранилища минимум три. Одно в переменной в git add -p, другое на диске, третье в переменной в git commit.

Нет. В Git такое хранилище ровно одно: $GITDIR/index. Всё остальное — это промежуточные его копии или копии его частей.

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

Не тебе решать, что кому нужно или нет. Мне, например, наличие персистентного индекса в моём повседневном workflow критически необходимо (т. е. индекс, который существует только в памяти команды hg commit --interactive, меня бы не устроил).

Мне, например, наличие персистентного индекса в моём повседневном workflow критически необходимо (т. е. индекс, который существует только в памяти команды hg commit --interactive, меня бы не устроил).

Просто для протокола: тебе его никто и не предлагал. Ты сам за него почему-то зацепился.

Просто для протокола: это контрпример к тому, что «[персистентный] индекс не нужен».

Просто для протокола: это контрпример

Это в лучшем случае непонимание, а скорее всего - передергивание.

к тому, что «[персистентный] индекс не нужен».

Если ты пытаешься использовать hg ci --interactive в качестве индекса, то... см выше.

У тебя проблемы с пониманием текста.

По-моему, это у тебя проблемы с формулированием текста. Или и с тем, и с другим.

Коммитить отдельные куски файла нельзя без индекса.

Можно.

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

Такой «индекс» есть и в Git. Т.е. в твоих терминах в Git два индекса (анонимус считает, что даже три).

См. мой ответ анонимусу.

Разница в том, что mq не вытаскивает ненужные детали в UI.

ditto

Если ты не понял ни меня, ни анонимуса, я тебе не доктор.

Я отлично понял вас обоих, и утверждаю, что вы оба несёте чушь и/или пытаетесь выдать свои задачи и потребности за единственно верные.

Коммитить отдельные куски файла нельзя без индекса.

Можно.

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

Бгг. Ты всё не можешь понять, что для коммита кусками «вышеприведённое определение индекса» нафиг не нужно, так же, как и сам индекс.

Я отлично понял вас обоих, и утверждаю, что вы оба несёте чушь и/или пытаетесь выдать свои задачи и потребности за единственно верные.

О, ты включил свой режим тупого игнорирования.

Разве грамотно написанные мутационные тесты не поймают подобный код?

Грамотно написанные мутационные тесты вкупе с грамотно написанным фазером и статическим анализатором на интервале в две недели ловят даже сишные ошибки памяти. Но мы почему-то до сих пор встречаем уязвимости :)

О, ты включил свой режим тупого игнорирования.

Да нет, читая твои посты, я с ним согласен. Тривиальную мысль «если индекс в Git нужен только для финального разбиения на нескольков коммитов, то это можно и без него» ты умудрился растянуть на пять полубредовых постов.

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

если индекс в Git нужен только для финального разбиения на нескольков коммитов

А если не только? Решил морально поддержать старого неосилятора? Молодец, чо.

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

Я понял, ты все-таки не умеешь формулировать. Ок.

А если не только? Решил морально поддержать старого неосилятора? Молодец, чо.

А если не только, то нужен :))

Вроде бинарная логика, нет?

Индекс, по определению — это хранилище объектов, которые войдут в следующий коммит.

Странное определение...

Странное, но корректное.

Вообще-то не совсем, ведь гитовый индекс хранит не только это. Но пусть так. В данном случае это не важно.

[ тут было излишне подробное описание про любую переменную, чтобы показать абсурдность такого определения ]

Нет. В Git такое хранилище ровно одно: $GITDIR/index. Всё остальное — это промежуточные его копии или копии его частей.

Но эти копии и части тоже удовлетворяют определению, а значит тоже могут считаться «индексом», по этому самому определению. Потому ж я и говорю, что определение странное.

Не тебе решать, что кому нужно или нет.

Вот для этого и было уточнение: сущность «ненужная», если без неё задачу можно решить так же или проще. Ты с этим согласен? А то мы как раз и выясняем, можно ли решить задачу коммита по кускам без индекса.

Мне, например, наличие персистентного индекса в моём повседневном workflow критически необходимо (т. е. индекс, который существует только в памяти команды hg commit --interactive, меня бы не устроил).

Возможно. Кто-то же пишет всякие расширения типа absorb для меркуриала, для чего-то оно используется. Хотя мне оно кажется ненужным, то есть я не сталкиваюсь с задачами где оно было бы полезно.

Кстати, мне любопытно, в каком повседневном workflow критически необходим персистентный индекс? А то может и мне это пригодится...

Вот для этого и было уточнение: сущность «ненужная», если без неё задачу можно решить так же или проще. Ты с этим согласен? А то мы как раз и выясняем, можно ли решить задачу коммита по кускам без индекса.

Это вопрос usability. Git'овый индекс позволяет тебе потом сделать git diff и насладиться результатом, запайпать результат куда-нибудь, в 'git stash' его положить или ещё что-нибудь сделать.

Лол. Ты бы хотя бы ознакомился с тем, как это делается в Rust.

лол, ты идиот.

И ведь действительно не гарантирует: https://users.rust-lang.org/t/memory-leaks-in-rust/18187

Это вопрос usability. Git'овый индекс позволяет тебе потом сделать git diff и насладиться результатом, запайпать результат куда-нибудь, в 'git stash' его положить или ещё что-нибудь сделать.

Ну так дифф можно было и после коммита получить. И в stash можно было коммит запхнуть. Собственно, без индекса и stash-то не нужен, можно просто скоммитить в отдельный бранч, так и возможностей больше.

Вообще, доказать нужность «персистентного индекса» в гите будет очень трудно, потому что остальные VCS справляются без него. У всех есть только workdir и repository. Только у гита зачем-то между ними есть индекс, и нельзя просто скоммитить в репозиторий, надо сначала отдельным набором команд откорректировать индекс.

Поэтому мне так интересны workflow, в которых персистентный индекс необходим.

Охренеть сколько срача вызвало появление очередной системы управления версиями на хипстерском языке.

Вы уже больше половины от того, что про покупку Red Hat IBM написали.

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

О паузах stop-the-world, которые порой длятся десятками секунд.

Ладно, плохой вышел пример, тут оба неюзабельные =)

Вообще, доказать нужность «персистентного индекса» в гите будет очень трудно, потому что остальные VCS справляются без него. У всех есть только workdir и repository. Только у гита зачем-то между ними есть индекс, и нельзя просто скоммитить в репозиторий, надо сначала отдельным набором команд откорректировать индекс.

Ты с кем Git сейчас сравниваешь? Конкретно?

Потому что персистентный индекс как раз и учит работь грязно и неаккуратно.

Как работают типичные гит-овцы и лично Линас: садимся за клаву и начинаем ХЕРАЧИТЬ под водовку и картофанчик. Так, падажжи, для фичи A сначала было надо поправить B. Ща ебана. Таааак, для B нужно сначало C. Херачим! Кстати надоб мейкфайл фиксануть а то опять не компиляется. Заодно README поправить штоб два раза не вставать. Опа, че я за говно вчера в соседнем файле написал, ща справим! Во, заебца! Потом к вечеру в рабочей копии 150 анрелейтед правок - чешем репу, как всё это говно поаккуратнее разбить на отдельные чейнджсеты. Мы ж не гопота какая, git ci -am «today's changes» делать! Так, git add -p, как Линас учил! Потом через месяц «так ща зделаем bisect опа абажжи хуле коммит b8f9876ea не собирается почему тесты не проходятся че за херню я тогда накоммитил та пох Линас говорил что индекс круто наверно я че-то не так делаю(((».

Как работает здоровый человек: включает голову и сначала думает, как разбить большое изменение на атомарные правки. Потом садится править. Сделал атомарную правку, прогнал тесты, закоммитил. Сделал атомарную правку, прогнал тесты, закоммитил. Ой, для фичи A надо сначала B. Не беда, делаем stash фичи A in progress и спокойно правим B. Оказывается, для B надо сначала C. Не беда, делаем stash B и правим C в чистой рабочей копии. Поправили С, прогоняем тесты, коммитим C. Делаем stash pop и возвращаемся к B, доделываем B, прогоняем тесты, коммитим B, делаем stash pop и возвращаемся к A, доделываем A, прогоняем тесты, коммитим A. Нет индекса - нет срача в рабочей копии, все коммиты протестированы, bisect всегда работает, нет больше слёзок.

Десятки секунд на сборку мусора, серьезно? В каких условиях ты с таким безобразием сталкивался? Это был штатный режим или аварийный режим в условиях существенной нехватки ресурсов? Вот в мире Java бывает такая засада, как concurrent mode failure, может ты про него?

Вообще, в нормальном режиме работы GC с поколениями паузы на три порядка меньше, скажем 20-100 мс. И это «длинные» паузы, их должно быть не так уж и много (зависит от сборщика). А «короткие» паузы это 2-10 мс. Никаких десятков секунд тут нет, что за страшилки.

И, прикинь, для всего этого индекс нафиг не нужен.

Мимо...

Они стреляют себе в ногу потом орут что «мама, у меня дыра в ноге».

Идеальный программист принимает идеальное решение с идеальным результатом.

Все примеры содержат явный выстрел, хотя язык даёт возможность не стрелять.

Си тоже даёт возможность не стрелять. Оснвоной вопрос лишь в том как скоро прогремит выстрел.