LINUX.ORG.RU

поддержка своего форка, мало отличающегося от оригинала

 , , слияние веток,


0

3

Подразумевается внесение небольших по объёму изменений в большой и активно развивающийся чужой проект и последующее поддержание этих изменений.

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

Видимо, нужен какой-то альтернативный ассиметричный 3-сторонний сливатель (3-way merge tool). Он, во-первых, должен понимать смысл каждой из сторон - вот это апстрим, вот это наши изменения. Не знаю, почему и не уверен, что не вру, но интуитивно есть такое ощущение.

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

Есть ли что-то такое в природе?

★★★★★

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

git

Две привязки, одна к оригинальному репозиторию, вторая к своей «копии». Пушить в свой, периодически merge или rebase с оригинальным.

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

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

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

А конкретно какие малые отличия ты предполагаешь? Если строчки в файлах переводов поменять, то можно настроить гит делать всегда checkout –ours на заданные файлы.

Если в сорцах, ну… старайся просто делать минимальные патчи.

a1batross ★★★★★
()

Может git pull –rebase подойдёт? Если в апстриме код который ты изменил не меняется кардинально, то получится примерно то, что ты хочешь.

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

Так бывает, если ты сам эти изменения подтверждаешь.

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

А конкретно какие малые отличия ты предполагаешь? Если строчки в файлах переводов поменять, то можно настроить гит делать всегда checkout –ours на заданные файлы.

Если в сорцах, ну…

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

Думаю, может быть, нужно копать в сторону улучшенных инструментов сравнения-слияния? Вот есть пара вопросов на SO:

https://stackoverflow.com/questions/5999495/using-an-alternate-diff-algorithm... - один про Markdown, к-рый в некоторых редакторах автопереносится и соответственно единицей текста является не строка, а абзац. Рекомендуют git diff --word-diff .

https://stackoverflow.com/questions/3450907/syntax-aware-diff-tools - про более умное сравнение ЯП с учётом синтаксиса, рекомендуют https://github.com/prettydiff/prettydiff/ и ещё что-то платное.

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

А разве –rebase влияет на способ сравнения файлов? Я не очень понял, но кажется, что он влияет только на способ преобразования истории.

den73 ★★★★★
() автор топика

Видимо, нужен какой-то альтернативный ассиметричный 3-сторонний сливатель (3-way merge tool). Он, во-первых, должен понимать смысл каждой из сторон

Есть, дорогой правда, «мейнтейнер» называется.

t184256 ★★★★★
()

Есть вариант при большом числе изменений делать в основном файле только код передачи управления в отдельный файл а основную логику держать отдельно.

ya-betmen ★★★★★
()
Ответ на: комментарий от den73

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

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

Видимо, нужен какой-то альтернативный ассиметричный 3-сторонний сливатель (3-way merge tool).

В ~/.gitconfig:

[merge]
        conflictstyle = diff3
Sorcerer ★★★★★
()

Чудес не бывает, тут нужен git mergetool (я использую meld) и метод пристального взгляда. Ну и делай свои патчи как можно более гранулярными, если есть возможность что-то не менять, то не меняй (либо меняй и проталкивай в апстрим). Ну кароче, что я тут в КО играю, ты и сам всё это прекрасно понимаешь.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от den73

Так бывает, если ты сам эти изменения подтверждаешь.

Возможно, что и я.

Что мешает для слияний или кодинга зависти отдельный аккаунт? И вообще, ‘‘не сидите под рутом, разделяйте полномочия’’

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

Видимо, нужен какой-то альтернативный ассиметричный 3-сторонний сливатель (3-way merge tool)

k3diff.

Он, во-первых, должен понимать смысл

Что понимать, простите? Если машина начнет понимать смысл, то человек будет не нужен.

поддержка своего форка, мало отличающегося от оригинала

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

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

Ты, наверное, мало работал с гит. Всё там есть. Создаёшь просто свою ветку и в неё мержишь из мастер ветки. Мердж бывает и без коммита. Можешь просмотреть что и как сливается, разрулить конфликты, и потом только закоммитеть мерджинг мастер апстрима в твою dev ветку. А потом уже пушишь dev в свою репу

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

Дай Бог (или в кого ты там веришь) здоровья тебе. Вчера открывал несколько статей про rebase, везде много букв, а ты вот взял и в одном предложении объяснил. Очень ценное умение в наш век, задумайся о том, как его монетизировать.

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

Очень ценное умение в наш век, задумайся о том, как его монетизировать.

Дык, кинь человеку 500 р на мобилку.

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

Плюсую.

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

Аналогично с простым переносом коммитов вверх посредством rebase. Иногда полезно делать.

А ТСу помимо таскания обновлений из исходной репы неплохо бы обложиться тестами, чтобы проверять, что обновления API не поломали его собственные фичи.

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

Да не вопрос, пусть пишет мобилку, только вряд ли это решит его финансовые проблемы в долгосрочной перспективе :)

Ты, наверное, мало работал с гит. Всё там есть.

Да не то, чтоб мало, я сейчас подобной деятельностью для своего любительского проекта занимаюсь, тяну сквозь время свои изменения

https://gitlab.com/budden/jaos/-/branches/active

И вот этот процесс удовольствия не доставляет. Насчёт мержа без коммита - попробую.

С методической точки зрения идея вынести свой код выглядит правильной, спасибо.

Если машина начнет понимать смысл,

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

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