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

git

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

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

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

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

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

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

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

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

А конкретно какие малые отличия ты предполагаешь? Если строчки в файлах переводов поменять, то можно настроить гит делать всегда 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/ и ещё что-то платное.

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

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

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

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

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

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

В ~/.gitconfig:

[merge]
        conflictstyle = diff3

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

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

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

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

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

k3diff.

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

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

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

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

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

Про rebase не слушай, он нахер не нужен, всё прекрасно работает через merge

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

Ну давай, создай пулл-реквест в более-менее серьезном проекте без использования rebase -i.

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

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

Плюсую.

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

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

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

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

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

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

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

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

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

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

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

это называется vendor branch и это умеет любая система контроля версий.

Даже svn: http://svnbook.red-bean.com/en/1.8/svn.advanced.vendorbr.html