Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"mergiraf - AST-оринтированный инструмент для трёхстороннего слияния в Git"	+/–
Сообщение от opennews (??), 14-Дек-24, 09:57
Опубликован релиз проекта mergiraf 0.4, развивающего драйвер для Git с реализацией возможности трёхстороннего слияния. Mergiraf поддерживает разрешение различных видов конфликтов при слиянии и может использоваться для различных языков программирования и форматов файлов. Возможно как отдельный вызов mergiraf для обработки конфликтов, возникающих при работе со штатным Git, так и замена в Git обработчика слияний для расширения возможностей таких команд, как merge,  revert,  rebase и cherry-pick. Код распространяется под лицензией GPLv3. В новой версии добавлена поддержка языков Python, TOML,  Scala и Typescript, а также проведена оптимизация производительности... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62402
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

2. "mergiraf - AST-оринтированный инструмент для трёхстороннего ..."	+/–
Сообщение от pyphon (?), 14-Дек-24, 10:05
Как я увидел функционал: 1. Обрабатываем код black`ом. 2. Прогоняем линтеры. 3. Задаём правила форматирования. 4. Прогоняем код black`ом. 5. Чтоб не жать одни и теже кнопки используем pre-commit. 6. ... 7. Profit. Никто в своём уме не будет тратить несколько дней на сведения одновременно нескольких веток с почти отрицательным результатом. Поэтому никто и не знает про эти инструменты, кроме нескольких деятелей искусства и науки от компьютерных наук.
Ответить | Правка | Наверх | Cообщить модератору

	5. "mergiraf - AST-оринтированный инструмент для трёхстороннего ..."	+1 +/–
	Сообщение от Аноним (5), 14-Дек-24, 10:25
	Мне понравилась вся суть продукта в одной картинке. https://mergiraf.org/img/scene_3.png из двух разработчиков эта штука сделала сиамских близнецов.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "mergiraf - AST-оринтированный инструмент для трёхстороннего ..."	+2 +/–
	Сообщение от Аноним (11), 14-Дек-24, 11:40
	Каноникализаторы и editorconfig - не панацея. Он помогает уменьшить число конфликтов от того, что один разраб предпочитает одно, другой - другое, и у каждого редактор настроен по-своему. Но конфликты слияния проистекают не только из этого. Это ОГРОМНАЯ ГОЛОВНАЯ БОЛЬ, когда ты не можешь заапстримить свои патчи, потому что апстрим - чудак. Самый ужас начинается, когда апстрим рефакторит структуру проекта одновременно с рефакторингом кода. В результате все файлы с твоими изменениями превращаются в почти сплошной конфликт слияния. ЗАПОМНИТЕ, ДЕТИ, ПЕРЕМЕЩЕНИЯ ФАЙЛОВ - СТРОГО В ОДНОМ КОММИТЕ, ЧИСТО ПОД ПЕРЕМЕЩЕНИЯ, А ИЗМЕНЕНИЯ ХОТЬ ОДНОГО СИМВОЛА КОДА - В ДРУГОМ.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	16. "mergiraf - AST-оринтированный инструмент для трёхстороннего ..."	+2 +/–
	Сообщение от Аноним (5), 14-Дек-24, 12:17
	Если проект нормально административно устроен все перемещения делает один человек он же по совместительству самый главный человек. Все остальное делают остальные люди и слушают что говорит главный человек. Все остальные перемещатели в очереди на прием к главному.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "mergiraf - AST-оринтированный инструмент для трёхстороннего ..."	+1 +/–
	Сообщение от fuggy (ok), 14-Дек-24, 13:41
	А какая разница в скольких коммитах сделано перемещение и рефакторинг. Ведь мержим мы всё равно с итоговым результатом. То есть конфликты будут уже на этапе с перемещением.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	38. "mergiraf - AST-оринтированный инструмент для трёхстороннего ..."	+/–
	Сообщение от Аноним (38), 14-Дек-24, 14:28
	Если файл просто 100%-перемещён, конфликтов именно с коммитом перемещения не будет, git поймёт, что изменение нужно перенаправить на другой файл. Когда же перемещение и рефакторинг свалили в кучу, то получаем дифф, где одна сторона /dev/null, и иди сам ищи, куда переместили. И вручную всё сливай.
	Ответить | Правка | Наверх | Cообщить модератору

3. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
Сообщение от Аноним (3), 14-Дек-24, 10:20
Дочитал новость до "развивается проект mergiraf. Этот написанный на Rust инструмент (занимает 21 MiB!)" и прекратил чтение.
Ответить | Правка | Наверх | Cообщить модератору

	6. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+2 +/–
	Сообщение от Аноним (6), 14-Дек-24, 10:27
	Да, на дискету не поместится. Плак плак.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от adolfus (ok), 14-Дек-24, 13:52
	Причем тут дискеты? Программа всегда загружается в физическую память и всегда там занимает места больше, чем на диске. Соответсвенно, всем остальным зело плохеет и все притормаживается из-за ужимания буферов и возросших в связи с этим обращений к дискам.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	–1 +/–
	Сообщение от Аноним (6), 14-Дек-24, 14:01
	Факт 1. У разработчиков обычно очень неплохое железо в связи с высокими зарплатами. Лично у меня 64 гига оперативочки, про OOM забыл как страшный сон, у меня весь рут "/" в tmpfs. Факт 2. Сабж висит в оперативке не 24/7, а во время мерджей, что происходит от силы 5 минут в день. Мой вопрос тебе: ты оперативку брал для того, чтобы любоваться ей, или чтобы использовать ее на максимум? Ты же надеюсь не покупаешь сервиз лишь для того, чтобы круглый год он пылился где-то на полке, а потом на новый год БОХАТО отведать оттуда оливье?
	Ответить | Правка | Наверх | Cообщить модератору

	35. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от Аноним (5), 14-Дек-24, 14:16
	А причем тут зарплаты. Нормальным разработчикам железо покупает работодатель. И уж нормальные разработчик как то обходятся без сабжевых костылей просто нормально организовывая работу.
	Ответить | Правка | Наверх | Cообщить модератору

	39. Скрыто модератором	+/–
	Сообщение от Аноним (38), 14-Дек-24, 14:30
	Ну раз у вас такая высокая зряплата, может вы всем нам по hi-end машине купите, каждому?
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	12. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	–2 +/–
	Сообщение от Аноним (11), 14-Дек-24, 11:48
	Вы уловили мой сарказм. В оригинале там было `(занимает целых 21 MiB!)`. На самом деле проект по исходникам всего-ничего занимает. С помощью нейросети вы сможете с весьма небольшими затратами переписать его на C++, на Си, на питон, на любой язык, какой вам нравится. Но зачем? Проект активно развивается. У меня план получше. Вместо переписывания проекта на Rust мы заменим Cargo на CMake. Если выкинуть всё дерево статически-линкуемых зависимостей, заменив его на сишные динамически-линкуемые библиотеки, сильно должен похудеть. И компилятор Rust можно вызывать из командной строки. Cargo - не особо нужен. Можно с небольшими затратами запилить полную поддержку Rust для CMake. Я имею в виду без участия Cargo вообще в каком-либо виде. И программить как на сишке. Программы должны от этого сильно похудеть.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	13. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от Аноним (11), 14-Дек-24, 11:53
	>Проект активно развивается. Я имею в виду, что ну вот вы перепишете проект на си. А дальше что? Разрабы запилят ещё десяток функций и перелопатят архитектуру. И вам придётся всё это портировать. Причём уже не нейросетью, а почти вручную, чтобы не превратить историю коммитов уже ВАШЕГО проекта в говно.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от Аноним (31), 14-Дек-24, 13:54
	Вы один из разработчиков? Скажем так, если ваш проект будет успешно собираться посредством gccrs, то портировать его я ни на что не буду.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от Аноним (38), 14-Дек-24, 14:36
	Нет, просто недавно провёл кое-какие эксперименты по компиляции программ без cargo (своих, без сторонних крейтов, с использованием сишных либ). Нет, gccrs нормально не соберёт вообще ничего. На данном этапе gccrs - это просто бесполезный хлам, который не может собрать тривиальнейшие программы по типу hello worldа. Я даже специально максимально её изувечил, насрав на все гарантии раста и обмазав unsafeом (в нём нет стандартной библиотеки раста - сюрприз! так что приходится на libc писать, с полным unsafeом, и и то не хватает фич (в расте всё очень сильно завязано на поддержку комилятора) даже для этого), чтобы gccrs компилировал. А он не компилирует.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от adolfus (ok), 14-Дек-24, 14:15
	"Если выкинуть всё дерево статически-линкуемых зависимостей, заменив его на сишные динамически-линкуемые библиотеки, сильно должен похудеть." Это такое всеобщее заблуждение относительно динамического связывания и статического. На самом деле все полностью наоборот. 1) Приложение с динамической линковкой занимает места в памяти больше, чем со статической. И если те .so, что оно загрузило в память, больше никем не используются, то по всем параметрам будет проигрыш. 2) Динамическая линковка требует дополнительных расходов на создание таблиц процедур и настройку при загрузке, плюс дополнительных расходов на косвенный вызов функций из .so в этих таблицах при каждом их вызове. 3) При первом вызове функции из даже загруженной в память другим приложением .so, динамический загрузчик делает достаточно сложную и требующую времени работу по выделению трех, как минимум трех страниц в памяти, где он разместит секции .text, .data и .bss для этой .so. На пользовательском уровне это лаг до нескольких секунд. Кстати, именно поэтому программа с динамической линковкой занимает больше места в памяти -- для каждой .so требуется своя такая, как минимум, тройка страниц. В программе со статической линковкой все, укладывается плотно и смежно, причем только то, что требуется программе -- не вся библиотека линкуется, а только та часть, к которой есть обращения. Так что если у вас есть .so, где есть помимо остального пара функций, типа преобразования градусов в радианы и наоборот, в память будет загружена вся .so, даже если кроме этих двух вы из этой .so ничего больше не используете.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	29. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от Аноним (-), 14-Дек-24, 13:49
	> Дочитал новость до "развивается проект mergiraf. Этот написанный на Rust > инструмент (занимает 21 MiB!)" и прекратил чтение. У питонистов и хрустиков есть кое-что общее: они пафосно решают навороченными тулсами какие-то совершенно левые задачи - решение которых кроме них никому нахрен не вперлось, навертев каких-то баззвордов, фреймворков, и будучи железно уверены что все это - круто. Хотя название у проекта прикольное конечно. Что-что, жираф для мержей? Это для тех до кого долго доходит чтоли? Хотя да, у этих проблема с заменой пробелов на табы будет, конечно :)
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

7. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
Сообщение от Аноним (7), 14-Дек-24, 10:47
Сильно не хватает такого инструмента. Постоянно конфликты в тех же resx файлах. Хотя там простейший xml.
Ответить | Правка | Наверх | Cообщить модератору

	37. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от adolfus (ok), 14-Дек-24, 14:23
	> Сильно не хватает такого инструмента. Постоянно конфликты в тех же resx файлах. > Хотя там простейший xml. xml специально придуман, чтобы осложнить программистам жизнь и раздуть код, как и его младший брат -- json.
	Ответить | Правка | Наверх | Cообщить модератору

8. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+2 +/–
Сообщение от nilsys (?), 14-Дек-24, 11:20
> ... примером чрезвычайно сложной системы. Сложные системы имеют одно общее свойство - они сложны - и вы не можете ожидать, что нужное сложное поведение возникнет само собой, случайно чего?
Ответить | Правка | Наверх | Cообщить модератору

	10. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	–1 +/–
	Сообщение от Аноним (10), 14-Дек-24, 11:33
	Сайт OpenNET - не сайт сугубо для программистов, а об СПО в общем, для дилетантов тоже, для того, чтобы использовать СПО, не только можно не быть программистом, но и даже лицензию можно не читать. Более того, это один из крупных сайтов, и новости с него копируют на сайты самых разных тематик. Системы контроля версий - это не инструмент сугубо для программистов. Один мой знакомый документы ворда в них версионирует. Всё лучше, чем папочка с десятком файлов и потенциалом для путаницы. Отсюда - описание для непрограммистов. Программисты знают, что это и зачем нужно и так. А вот непрограммисты без пояснения скажут "какая-то мутная программистская хрень, мне не нужно", хотя в этот инструмент можно приделать и бэкенд для документов ворда при желании. Текст написан в субъективном и неформальном стиле. Как автор текста - мне и решать. Не казённым же официозом писать? В тексте присутствуют некоторые проблемы. В частности "направленный граф" по-русски будет ориентированным. Это потому, что я написал текст сначала на английском, потом дал задание нейросети улучшить его стиль, сохраняя контент, а потом дал ей же задание перевести на русский. Не смотря на применение нейросети, текст оригинальный. Преамбула для дилетантов тоже писалась мною. Собственно, нейросетью в основном именно она и была обработана с целью сделать более доступной для массовой аудитории. Потом сидел и правил текст на русском, но у меня крашнулся браузер и часть работы была потеряна. Пришлось восстанавливать из истории буфера обмена, через который копировал с вкладки с нейросетью. У нейросети, кстати, куча огрехов была, и я их видимо не все выловил (таких как оставшиеся слова "снимок" и "наборы изменений", ну уж нет, если "снимок" ещё более менее нормально, то "набор изменений" - это слишком длинно, не годится, давайте использовать просто не будем переводить компьютерные термины, промаркировав их английским, а снимки оставим фотографам). В процессе выяснилось, что значительный кусок, который я писал уже изначально на русском, потерялся, так как в буфер вообще не попадал. Так правка перевода термина DAG вообще вышла из фокуса, каюсь. Весь субъективный стиль, который вы видите в статье, включая КАПС и некоторые саркастические ремарки, намерен, его пришлось восстанавливать вручную там, где я считаю, что он нужен. Как автор статьи - имею право так считать, не находите? Когда свою статью будете писать на этот сайт (а у меня тут довольно много было статей опубликовано) - тогда и вы будете решать, стоит ли переводить терминологию или собственные существительные, что вы хотите сказать, какой стиль использовать, и какая правильная доза сарказма и его едкости. А когда статью пишу я - это мне решать.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+2 +/–
	Сообщение от НейроАноним (?), 14-Дек-24, 12:36
	Да вы что! У вас в голове полный бардак! Сайт OpenNET – это не просто сайт для каких-то бездельников или дилетантов! Он создан для людей, которые хотят знать больше, хотят развиваться, а не для тех, кто сидит с пивом на диване и не понимает, что происходит в мире технологий. Системы контроля версий - это не игрушки для программистов, это инструменты для всех, кто хочет организовывать свою работу! Вы думаете, что только программистам нужны такие решения? Да нет, любой нормальный человек, который хоть раз создавал документы, поймет, как это полезно! Забудьте о стихийном беспорядке на вашем компьютере, а используйте нормальные системы, которые упрощают жизнь! Ваши попытки сделать это "доступным" и "простым" - это просто отмазка! Настоящий специалист должен уметь разбираться в терминах и алгоритмах, а не прятаться за множеством неуместных шуток и сарказма. Если вы хотите, чтобы вас серьезно воспринимали, ведите себя соответственно! А ваша "невежественная" лень в отношении перевода и терминологии – это просто позор! Вы пишете, как будто вся эта информация для какого-то абсолютного идиота, который не знает, что такое "ориентированный граф"! Человек, который хочет учиться, сможет разобраться, а не будет плюнуть на всё и говорить, что это "программистская хрень"! Так что, хватит уже оправдываться! Беритесь за ум и начинайте писать так, чтобы каждому было понятно – и программисту, и простому пользователю! Никаких отговорок!
	Ответить | Правка | Наверх | Cообщить модератору

	23. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от freehck (ok), 14-Дек-24, 13:03
	> Сайт OpenNET – это не просто сайт для каких-то бездельников или дилетантов! Отличная формулировка. То есть, всё-таки для бездельников и дилетантов. =)
	Ответить | Правка | Наверх | Cообщить модератору

	36. Скрыто модератором	+/–
	Сообщение от Я не Аноним (?), 14-Дек-24, 14:20
	Но не для каких-то, а для вполне конкретных переписанных и зафиксированных. Все остальные бездельники и дилетанты идут лесом.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
	Сообщение от adolfus (ok), 14-Дек-24, 14:31
	> Системы контроля версий - это не инструмент сугубо для программистов. Один мой > знакомый документы ворда в них версионирует. Всё лучше, чем папочка с > десятком файлов и потенциалом для путаницы. Интересно, как бинарники можно в систех управления версиями (СУВ) хранить. Даже если .docx или .odt развернуть, то получится каталог из нескольких xml и бинарников, которые на сегодня никто из СУВ адекватно обрабатывать не умеет. Ну или я проспал лет десять-пятнадцать и за это время кто0-то что-то напсал на эту тему.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

14. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
Сообщение от Аноним (11), 14-Дек-24, 12:05
Ещё забыл написать в статью парочку своих мыслей (тоже уже написанных, но потерянных при краше). Нужен инструмент для применения патчей. Для этого патчи надо как-то хранить. Патчи gumtree привязаны к оригинальному исходнику. Соответственно, для сериализации патчей в файл придётся сохранять оригинальный исходник в каком-то виде, чтобы патч применить даже на изменённый исходник. Вы заметьте: инструмент делает строго трёхстороннее слияние. Потому что для понимания семантики важно понимать, что изменилось, а что сохранилось. Соответственно, для патча между двумя файлами нужно будет сформировать синтетическую базу на основе обеих версий. Файл патча должен содержать в себе как эту синтетическую базу, так и изменения поверх этой синтетической базы. При этом, синтетическую базу можно в некоторой степени подрезать, заменяя части, соседи которых не были затронуты, на плейсхолдеры. Но важно понимать - любая подрезка дерева обрезает возможности применения патчей в случае, если обрезанные части будут перенесены в другое место дерева или переименованы. Как компромисс можно обрезаемые части векторизовать с помощью нейросети, и хранить именно векторы.
Ответить | Правка | Наверх | Cообщить модератору

18. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+2 +/–
Сообщение от Анониссимус (?), 14-Дек-24, 12:27
Звучит интересно! Использовать это я, конечно, не буду...
Ответить | Правка | Наверх | Cообщить модератору

	19. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+1 +/–
	Сообщение от eugener (ok), 14-Дек-24, 12:29
	вот-вот, я тоже с интересом прочитал и то же самое подумал.)
	Ответить | Правка | Наверх | Cообщить модератору

21. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+2 +/–
Сообщение от НейроАноним (?), 14-Дек-24, 12:32
- Опубликован релиз проекта Mergiraf 0.4 с поддержкой трёхстороннего слияния и разрешения конфликтов в Git. - Mergiraf поддерживает различные языки программирования и форматы файлов, а также может использоваться как отдельный инструмент для обработки конфликтов. - В новой версии добавлена поддержка Python, TOML, Scala и TypeScript, а также оптимизация производительности. - Программное обеспечение иллюстрирует эволюцию сложных систем, где каждая версия представляет собой набор функций, а изменения — мутации, формирующие граф. - Snapshot-ы, полученные в результате слияния коммитов, сложно обрабатывать, что приводит к необходимости избегать их. - Современные системы контроля версий, такие как Git, организуют snapshot-ы в виде ориентированных ациклических графов, что помогает создавать семантически значимую историю проекта. - Проблемы построчного алгоритма могут привести к нерабочему коду при слиянии изменений, и разработчику необходимо вручную разрешать конфликты. - Для применения патчей необходим инструмент, который будет хранить патчи, привязанные к оригинальному исходнику, с сериализацией оригинала. - Инструмент должен выполнять трёхстороннее слияние, учитывая изменения и сохранённые элементы, с возможностью оптимизации синтетической базы.
Ответить | Правка | Наверх | Cообщить модератору

24. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
Сообщение от Вы забыли заполнить поле Name (?), 14-Дек-24, 13:41
Когда в описании к софтине начинает объясняться почему она такая сложная, то кажется, что дальше можно не читать.
Ответить | Правка | Наверх | Cообщить модератору

27. Скрыто модератором	+/–
Сообщение от Аноним (27), 14-Дек-24, 13:43
В разрабатываемой ветке устраивают параллельную реальность, а потом она не мержится в основную (продакшеновую), потому что в ней уже половина кода из разрабатываемой. Ясен пень, нужны сложные инструменты. Вместо того, чтобы ответственных за возникновение такой ситуации выгнать из профессии с волчьим билетом! Из моей собственной практики, манагерам абсолютно пофиг, что программисты делают в гите. Рак с ветками разводят сами разработчики, по собственной же инициативе. Попытки прекратить бардак всячески саботируют. "Мне сказали в прод сделать хотфикс и я зделол" brainlet.png Кому любопытно, нужно иметь ровно одну разрабатываемую ветку и никогда не пихать в основную дублируя коммиты (вместо этого фиксы в разрабатываемую и чери пих из разрабатываемой в основную). Чтобы это получалось, нельзя допускать серьезных расхождений между разрабатываемой и основной. Ломающие изменения в разрабатываемой - значит должен произойти релиз (основная подтягивается до этой редакции). Тогда фиксы легко зайдут черипиком из разрабатываемой. В 99.9% проектов не нужно никаких более сложных процессов. Кому интересно, это адаптация транковой модели "для тупых". Саму транковую модель народ массово неверно интерпретирует, разводя старый добрый рак с параллельными реальностями. >ответов на вопросы вроде "Зачем была введена эта низкоуровневая деталь (например, переменная)?", В переменной хардкодятся креды или эндпойнт апи, какое значение должно зайти? И тому подобный кретинизм.
Ответить | Правка | Наверх | Cообщить модератору

28. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
Сообщение от Аноним (28), 14-Дек-24, 13:47
В тексте какой-то корчеватель
Ответить | Правка | Наверх | Cообщить модератору

32. "mergiraf - AST-ориентированный инструмент для трёхстороннего..."	+/–
Сообщение от fuggy (ok), 14-Дек-24, 14:00
Это новость или словоблудие. Какие-то рассуждения с введением в историю тулзов. Этому не место в новости. А вот примеров как включить и настроить или полный список языков и возможность добавить свой язык можно было добавить. > слияние же - это почти как rebase, просто структурирует граф коммитов по-другому, в результате чего им становится неудобно манипулировать, поэтому от слияний стараются отказаться в пользу rebase-ов Сильное заявление. Разводить холивар я не буду, но у ребейзов свои проблемы, потому что это переписывание истории. Я понимаю почему для лучшего применения этой тулзы хорошо когда изменения идут одно за одним. Почему бы тогда не применить Patch theory и было бы отличное решение из смеси Darcs с математическим подходом на основе популярного git. Я определённо попробую это в деле. Список поддерживаемых языков больше чем написано в новости. Но кто гарантирует что после этого слияния проект будет билдится и работать также. Когда возникает конфликт при мерже это уже звоночек что нужно обратить внимание и вчитаться в код. Тут же это будет происходить тихо автоматом, а эвристики могут и ошибаться.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема